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Preface 



Constraint programming is a higly declarative and relatively new approach to 
computing in which the programming process consists mainly of stating a set of 
requirements (the constraints) and solving them via general as well as domain- 
dependent methods. In the last decade, constraint programming has evolved 
from a basic research idea to a powerful programming paradigm, that is increa- 
singly used to model and solve many hard real-life problems. Many areas of 
computer science have taken advantage of the power of constraints, like opti- 
mization, numerical computing, natural language processing, computer algebra, 
and computer graphics, to mention a few. 

This book contains a selection of contributions on constraints, most of which 
were presented at a workshop held in Paphos (Cyprus) on October 25-27, 1999. 
The workshop was the third in a row in a series of joint annual workshops 
organized by the Compulog Net area on Constraint Logic Programming and the 
ERCIM Working Group on Constraints. As these workshops repeatedly attreicted 
interesting and high quality contributions, the organizers decided this time to 
publish its proceedings. All contributions were refereed. 

ERCIM, the European Research Consortium for Informatics and Mathema- 
tics, is an organization dedicated to the advancement of European research and 
development in information technology and applied mathematics. It comprises 
institutions from fourteen European countries. The ERCIM Working Group on 
Constraints was founded in 1996 and since then it has been organizing annual 
workshops. 

Compulog Net, the European Network of Excellence in Computational Logic, 
comprises over 100 nodes from 20 European countries, representing leading uni- 
versities, research centres, and industrial companies. The aim of this network is 
to support all phases of technological change - invention, innovation, diffusion - 
associated with the research, development, and application of logic-based techni- 
ques and methods in all areas of computing. The Constraint Logic Programming 
area of Compulog Net deals in particular with extensions of logic programming 
to constraints and concurrent programming. 

The editors would like to take the opportunity to thank the authors for having 
agreed to contribute to this volume and the referees for their useful reviews of 
the submitted papers. We hope that the present volume will be of interest to 
the researchers working on all uses of constraints, for programming, modelling, 
and processing. 
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Abstract Reliably solving non-linear real constraints on computer is 
a challenging task due to the approximation induced by the resort to 
floating-point numbers. Interval constraints have consequently gained 
some interest from the scientific community since they are at the heart 
of complete algorithms that permit enclosing all solutions with an ar- 
bitrary accuracy. Yet, soundness is beyond reach of present-day inter- 
val constraint-based solvers, while it is sometimes a strong requirement. 
What is more, many applications involve constraint systems with some 
quantified variables these solvers are unable to handle. Basic facts on 
interval constraints and local consistency algorithms are first surveyed 
in this paper; then, symbolic and numerical methods used to compute 
inner approximations of real relations and to solve constraints with quan- 
tified variables are briefly presented, and directions for extending interval 
constraint techniques to solve these problems are pointed out. 



1 Introduction 

Interval constraints are integrated in the constraint solving and optimization en- 
gines of many modern constraint programming languages, and have been used 
to solve industrial applications in areas like mechanical design, chemistry, aero- 
nautics, medical diagnosis or image synthesis. The term “interval constraint” is 
a generic one denoting a constraint (that is, a first order atomic formula such 
as an equation/inequation, or more generally a relation) in which variables are 
associated with intervals denoting their domains of possible values. In general, 
intervals are defined over real numbers though the concept is general enough to 
address other constraint domains (e.g. non-negative integers, Booleans, lists, sets, 
etc.). When defined over reals, interval constraint sets are often called continuous 
constraint systems or numeric constraint satisfaction problems (numeric GSPs). 

Interval constraint processing associates propagation and search techniques 
developed in artificial intelligence, and methods from interval analysis. The main 
idea — also called interval propagation — is, given a set of constraints S involving 
variables {ui, . . . , u„| and a set of floating-point intervals (Ii, . . . , /„} represent- 
ing the variables’ domains of possible values, to isolate a set of n-ary canonical 
boxes (Gartesian products of intervals whose bounds are either equal or con- 
secutive floating-point numbers) approximating the constraint system solution 
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space. To compute such a set, a search procedure navigates through the box 
/i X • • • X alternating pruning and branching steps. 

The pruning step uses a relational form of interval arithmetic 1231 . Given a 
set of constraints over reals, interval arithmetic is used to compute local approx- 
imations of the solution space for a given constraint. This approximation results 
in the discarding of values from the variables’ domains and these domain modi- 
fications are propagated through the whole constraint set until reaching a stable 
state. This stable state is closely related to the notion of arc consistency nmni, 
a well-known concept in artificial intelligence. The branching step consists in a 
bisection-based divide and conquer procedure on which a number of strategies 
and heuristics can be applied. 

Interval constraints were first introduced by J. G. Gleary in jO]. The initial 
goal was to address the incorrectness of floating-point numerical computations in 
the Prolog language while introducing a relational form of arithmetic in a closer 
adequation with the language formal model. These ideas, clearly connected to 
the concepts developed in constraint logic programming CM, have then been 
implemented in BNR-Prolog |2S|. Many other constraint languages and systems 
such as CLP(BNR) 13, Prolog IV j^T] or Numerica have since used interval 
constraints as their basic constraint solving engine. 

The paper is organized as follows: interval constraints are first introduced in 
Section 0 interval arithmetic supporting them is described along with its prop- 
erties and limitations; the interval constraint solving process based on local con- 
sistencies and filtering is then presented in Section 0 where hull consistency jSj 
and box consistency 0 are theoretically described. Limitations of present-day 
interval constraint solving techniques, viz. the computation of sound solutions 
and the handling of constraint systems with quantified variables, are pointed out 
in Section 0 and numerical as well as symbolic methods used to solve them are 
surveyed. Last, some directions to enhance interval constraint solving techniques 
are given. 

2 Interval Constraints 

In order to model the change from continuous domains to discrete domains 
induced by the shift from reals to machine numbers, Benhamou and Older 0 
have introduced the notion of approximate domain over the set of real^ R. 

Definition 1 (Approximate domain). An approximate domain A over R is 
a subset of the power set of R, closed under intersection, containing R, and for 
which the inclusion is a well-founded ordering. 

The outer approximation w.r.t. A of a real relation p, written apx^(p), is 
then defined as the intersection of all the elements of A containing p. A dual 

^ The original definition is more general but the one given here is sufficient for our 
purpose. 
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notion of inner approximation, to be investigated in Sectional can be defined as 
the union of all the elements of A contained in p. 

This section focuses on two widely used approximation sets over R, namely 
intervals and unions of intervals. The shift from reals to intervals is first de- 
scribed; interval constraints are then introduced. 



Intervals 

Let R be the set of reals compactified with the infinities {— oo, -|-oo} in the 
obvious way, and F C R a finite subset of reals corresponding to binary floating- 
point numbers in a given format j I dj . Let be F U {— oo,-|-oo}. For every 
g G F°°, let g+ be the smallest element in F°° greater than g, and g~ the greatest 
element in F°“smaller than g (with the conventions: (-|-oo)+ = -l-oo, (—00)“ = 
—00, (-|-oo)“ = max(F), (—00)+ = min(F)). For every r G R, let [r] be the 
smallest element in F°“ greater than r, and [rj the greatest element in F°“smaller 
than r. 

A closed floating-point interval is a connected set of reals whose lowest up- 
per bound and greatest lower bound are floating-point numbers. The following 
notations is used as a shorthand: [g .. h] = {r G R | g < r < h}. 

Let I be the set of closed/open fioating-point intervals, and U the set of unions 
of disjoint closed intervals. A Cartesian product of n intervals JB = Ji x • • • x /„ is 
called a box; a domain D is either an interval / or a union U of disjoint intervals. 
A non-empty interval 7 = [g .. h] is canonical whenever h ^ g+. An n-ary box B 
is canonical whenever intervals 7 i, . . . , /„ are canonical. 

A real relation p may be conservatively approximated by the smallest (w.r.t. 
set inclusion) union of disjoint boxes Union(p) = apxu(p) (resp. the smallest 
box Hull(p) = apxi(p)) containing it (see Fig. P). In the sequel, the following 
approximations are used: Union(p) = apxy(p), and Hull(p) = apxi(p). 




Fig. 1. Approximations of a relation over the intervals. 



Interval arithmetic, introduced by R. E. Moore in m , extends real arithmetic 
so as to compute supersets of the corresponding real quantities (completeness 
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property). Interval operations are implemented by outward-rounded floating- 
point computations over the bounds of intervals so as to keep numerical errors 
under control, as follows: 

©: [g..h],[g'..h']^[L(g + g')J .. r(h + h')l] 

0: [g..h],[g'..h']^[L(g-h')J ..r(h-g')l] 

0: [g .. h], [g' .. h'j [[min(gg',gh',hg',hh')J •• |'max(gg', gh', hg', hh')l] 



The interval extension of a real function / is a key notion of interval arithmetic 
that permits enclosing the range of / over a domain. 

Definition 2 (Interval extension). An interval extension (also called inclu- 
sion function ) of a function f : M” — >■ K zs a mapping F : I" — >■ I such that for 
all /i , . . . , In G I . Ti G , . . . , Tyj G In f • • • An) ^ I^{Il 7 • ■ • j In) ■ 

The definition is general enough to permit the design of various kinds of 
interval extensions through symbolic transformations of function expressions, 
Taylor expansions or other approximation techniques. We introduce two widely 
used notions, namely the natural interval extension and the Taylor interval ex- 
tension. 

The natural interval extension corresponds to a syntactic extension of a par- 
ticular expression of the function to be approximated. It is obtained from the 
given expression by replacing each constant r by Hull({r}), each variable by an 
interval variable with the same domain, and each operator by the corresponding 
interval one. Unfortunately, the natural interval extensions associated with two 
different expressions are generally different. For example, let / be the interval 
[—0.5 .. 1], and /: x — x a, real function. If we evaluate the natural interval 
extensions of four different expressions of /, we obtain: 



e\{x) = x{x — 1) 

e2{x) = X X X — X 
es{x) = x^ — X 

64 ( 0 :) = {x — 0.5)^ — 0.25 



Ei{I) = [-1.5 .. 0.75] 
£ 2 ( 1 ) = [-1.5 ..1.5] 
Es{I) = [-1 .. 1.5] 
E 4 I) = [-0.25 .. 0.75] 



This main weakness of interval arithmetic is known as the dependency problem. 
Its source lies in the decorrelation of several occurrences of a variable during 
interval evaluation. When an expression is a linear term (only one occurrence per 
variable), the evaluation is the exact range (modulo rounding errors) (theorem of 
single occurrences by Moore) as is the case for Exp. 64 in the previous example. 

The Taylor interval extension corresponds to the Taylor extension over the 
reals where the error term is bounded by an interval term. Let / be a real 
function with continuous derivatives of order n, E an interval extension of /, 
{k = 1 .. . n) an interval extension of the derivative of / of order k, I an 
interval domain, and a a point in I. The Taylor interval extension of order n is 
defined as: 

Tn{X) = E{a) + ^^~^" F^(a) 0 (-^~ «)" fW(/) 

k\ n! 
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where the generic error term € I) is bounded by In practice, 

the first-order Taylor extension Ti{X) = F{a) -I- (X — a)F'{I) is the most com- 
monly implemented. Finally, since the Taylor (resp. natural) extension converges 
to the range of the function with a quadratic (resp. linear) convergence on the 
width of domains, it is generally used for tight (resp. large) domains. The reader 
is referred to j2,'-ir2tW,'S.‘Tj for a more complete discussion about interval extensions. 



Constraints 

In the sequel, a real (resp. interval) constraint is an atomic formula built from 
a real (resp. interval)-based structure and a set of real (resp. interval)-valued 
variables. Given a real constraint c, a variable v and a box B, let denote the 
underlying relation, Var(c) be the set of variables occurring in c, and Dorris (u) 
be the domain of u in B. 

An interval extension of a relation p C R" is a relation i? C I" such that for 
all /i , . . . , Iji € I. 3ri G € Iji s.t. (ri,...,r,i) € p (/^ , . . . , /y^) € R. 

Given a real relation symbol o G {=, ^}, the corresponding interval relation 

symbol [xi is usually interpreted as follows: 

V(I, I' G I) 3(r G I) 3(r' G /') : r o r' ^ I I' 

In other words, the associated interval constraint is true if there exists at 
least one tuple included in the given intervals verifying the corresponding real 
constraint. For example, the following expressions hold: given X — [g .. h] and 
Y = [g' .. h'], X = Y if and only if X DY yf 0, while X ^Y whenever g ^ h'. 

Numeric Constraint Satisfaction Problems 

A numeric constraint satisfaction problem (numeric GSP) is a conjunction of real 
constraints ci A • • • A Cm on a set of variables {ui, . . . , u„} to which are associated 
interval domains of possible values {/i, . . . ,/n}- Tbe solution space of the GSP 
(see Fig. 0) is the n-ary relation over R defined as the intersection of the relations 
Pa (modulo appropriate cylindrification) and the Gartesian product of domains 
/i X • • • X {search space). 

The solving of a numeric GSP consists in isolating a set of n-ary boxes in- 
cluded in the search space approximating the solution space. To compute such a 
set, a search procedure navigates through the search space alternating pruning 
and branching steps. In the framework of interval constraints, the pruning step, 
also called interval narrowing or interval propagation, is implemented by local 
consistency algorithms to be described in the next section. 



3 Interval Narrowing 

Given a numeric GSP, an interval narrowing process generates a box approxi- 
mating its solution set. In the interval constraint framework, this approximation 
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Fig. 2. A numeric CSP. 

function NC3 (5: constraint set, B: box): box 
% Output box is necessarily included in the input box 
begin 

Queue all constraints from 5 in Q 
repeat 

Select a constraint c from Q 

B' <r- narrow(f?, c) % Narrow down B with respect to c 

if B' = 0 then return 0 % Inconsistency of the constraint system 

Let 5' = {c G 5 I G Var(c), B'v C 

% Queue the constraints whose variables' domains have changed 
Q^iQuS')\{c} 

% Delete c from Q 
B i- B' 

until Q is empty 

return B 

end 



Alg. 1. Interval Narrowing Process 



is generally computed by applying the algorithm described by Alg.d called here 
NC3 to reflect its similarity to the arc consistency algorithm AC3 l_20j . 

The call to Function narrow() in NC3 is an algorithmic narrowing process. 
A constraint narrowing operator (CNO) is associated to the underlying relation 
Pc of each constraint c in S. CNOs are complete, contracting, monotone, and 
idempotent operators mapping boxes to boxes, that is: for every boxes B, B': 



completeness : 
contractance : 
monotonicity : 
idempotence : 



Bn pC Nc{B), 

Nc{B) C B, 

BnB' Nc{B) C Nc{B') 

NciNciB)) = Nc{B). 



The algorithm stops when a stable state is reached, i.e. no (strict) narrowing 
is possible with respect to any constraint. The result of the main step is to 
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remove (some) incompatible values from the domains of the variables occurring 
in c. The main properties of NC3 are the following: 

— it terminates in finite time, since each step is contracting and the inclusion 
relation over an approximate domain is a well-founded relation; 

— it is complete (the final box contains all solutions of the initial system in- 
cluded in B), since each narrowing operator is complete; 

— it is confluent (selection of constraints in the main loop is strategy indepen- 
dent), and it computes the greatest common fixed-point of the constraint 
narrowing operators that is included in the initial box p). 

Different constraint narrowing operators may be defined, that result in dif- 
ferent local consistency notions. A system is said to be locally consistent (with 
respect to a family of constraint narrowing operators) if the Cartesian product 
of its variables’ domains is a common fixed-point of the constraint narrowing 
operators associated with its constraints. The main local consistency notions 
used in numeric constraint satisfaction problems are: first order local consisten- 
cies deriving from arc consistency {hull consistency or 2B consistency jSliDlj . hox 
consistency [Z|), and higher order local consistencies deriving from k-consistency 
{SB consistency, kB consistency box(2) consistency |2BI) to be described at 
the end of this section. 

3.1 Hull Consistency 

Discarding all values of a box B for which a real constraint c does not hold is 
not achievable in general. This section presents a coarser consistency called hull 
consistency 0 consisting in computing the smallest box that contains pcC\ B. 

Definition 3 (Hull consistency). A real constraint c is said hull consistent 
w.r.t. a box B if and only if B = Hull(pc H B). 

Due to round-off errors introduced by the use of floating-point numbers, com- 
puting the interval enclosure of a real set 7^ is a difficult task in itself. Many 
solvers partly overcome this problem by enforcing hull consistency over a decom- 
position of primitive constraints rather than considering the user constraint 
c. A constraint c is called a primitive constraint on the approximate domain 
A if and only if one can exhibit n projection narrowing operators Nf , . . . , Njj, 
defined from A” to A, such that: 



VD = Di X ••• X {!,..., n}: 7V,'=(D) = apx^(p,W(D) n D^) 



where 



Pc'^\B) — {fk G R I 3ri S Ji, . . . , 3rfe_i S 

3rfc+i e 4+1, . . . ,3r„ e s.t. (ri, . . . , r„) e pj 
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is the k-th canonical extension of the real n-ary constraint pc w.r.t. the box 
B yS4] . Intuitively, a primitive constraint is a constraint for which one is always 
able to compute the best possible approximations of its projections over A. 

In most constraint programming systems, the notion of primitive constraint 
corresponds to a constraint composed of one operation symbol, e.g. + y = -z”, 
“x — y = z”, etc, and the CNOs are efficiently implemented using relational 
interval arithmetic ^ (see an example below). For example, the constraint c: x-\- 
yx z = t might be decomposed into = {y x z = a, x a = t} with the addition 
of the new variable a. Unfortunately, the introduction of new variables drastically 
hinders domain tightening for the variables the user is interested in. As pointed 
out in [Zj, this is particularly true when the same variables appear more than 
once in the constraints since each occurrence of a variable v is considered as a 
new variable v' with the same domain as v {dependency problem m)- 

Example 1 (A CNO for c: x -\- y = z). Enforcing hull consistency for the con- 
straint c: x-\-y = z and domains ly, and 1^, is done by computing the common 
fixed-point included in B = x ly x 1^ of the following projection operators: 

Nl{B) = 4 n (4 e h), nI{B) = 40 (4 e 4), and nI{B) = 4 n (4 © 4). 

where © and © are the natural interval extensions of — and -I-. 

As pointed out by Van Emden the projection operators N^,N^,N^, for 
a constraint of the form xoy = z may all exist even if the function o has no 
inverse. For example, consider the case where o stands for the multiplication 
over !□: Nl computes the smallest union of intervals containing the set {r^. G 
4 I G ly, G 4 : fx x fy = ©}• Hence, it is defined even when 0 G 4- 

3.2 Box Consistency 

Box consistency |Z] has been introduced to avoid decomposing constraints, thus 
tackling the dependency problem for variables with many occurrences. 

The original box consistency definition [3 is based on closed intervals and 
on the natural interval extension of constraints. It has been generalized in 0by 
permitting the use of other interval extensions, and by parameterizing it with 
two approximate domains. This last modification allows to take into account 
some variations over the original definition such as the one given by Collavizza 
et al. m3, where quasi-zeros are approximated by open intervals while the output 
result is a closed one. The definition admits using a different interval extension 
for each projection. 

Definition 4 (Box_ 4 j^^ 2 ,r consistency). Given A\ and A 2 two approximate 
domains, let c be a real n-ary constraint, E = {Ci, . . . , C„} a set of n interval 
extensions of c, k an integer in {1, . . . , n}, and D — D\ x ■ ■ ■ x Dn a Cartesian 
product of domains. The constraint c is said box consistent w.r.t. D, a variable 
Xk of c, and Cf if and only if: 

Dk = ap^Ai i^k n {rfc € M I 

Ck{Di^ . . . J Dk — lt • • • ; -^n)}) (1) 
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Moreover, c is said box consistent w.r.t. F and D iff Eq. (QJ) holds for all k in 
,n}. A constraint set C is said box consistent w.r.t. a Cartesian product 
of domains D whenever every n-ary constraint c £ C is box consistent w.r.t. D 
and a set E of n interval extensions of c. 

It is then worthwhile noting that boxj|^ consistency — where C is 

the natural interval extension of the considered constraint, and In(resp. lo) is the 
set of closed (resp. closed/open) intervals — corresponds to the definition of box 
consistency as given by Collavizza et al. CO], while boxj|^ (;;} consistency 

is equivalent to the original definition 0. For the sake of clarity, boxj|^ 
consistency is henceforth shortened to “boxo consistency.” 

BoXq consistency is enforced by Alg. BCSrevise over a n-ary constraint c as 
follows: CNOs A^i, . . . , are associated to the univariate interval constraints 
CP , . . . , obtained from the interval extension C of c by replacing all the 
variables but one by their domains. Each reduces the domain of one vari- 
able by computing the leftmost and rightmost canonical intervals (leftmost and 
rightmost quasi-zeros) such that holds (see Fig. OD. Apart from this tech- 
nique not requiring the addition of any additional variable, these operators can 
be efficiently implemented with an algorithm mixing interval Newton methods, 
propagation and bisection-based search. 



As said in 0, boxo consistency computation is far more effective than hull 
consistency computation when dealing with complex constraints involving the 
same variables many times, since the global processing of these constraints avoids 
losing some useful information. Nevertheless, finding the leftmost and rightmost 
quasi-zeros is computationally expensive. Moreover, it must be done for every 
variable occurring in the constraint. Therefore, boxo consistency is generally 




New domain 



Fig. 3. Enforcing box consistency over f(x) = 0,x G [a .. b]. 
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not the solution of choice when a complex constraint involves many different 
variables. 

However, the generalized definition for box consistency (Def. 0) permits de- 
vising a hybrid algorithm 0 that uses straight interval evaluation for narrowing 
the domains of the variables occurring only once in a constraint, while resorting 
to Alg. BCSrevise for the other variables. Such an algorithm has been shown to 
outperform both Alg. BCSrevise and the one used to enforce hull-consistency. 
The reader is referred to the aforementioned reference for details. 

Higher-order local consistencies are based on their first-order counterparts. 
Operationally, the idea is to improve enclosure accuracy by discarding sub- 
intervals of the locally consistent domains that can be asserted locally incon- 
sistent. The general procedure is as follows: consider a hull consistent interval 
constraint system {S, B). An equivalent SB-consistent system is a system (5, B') 
such that, for every variable v, if B' y = [a, &], the system (5, (resp. 

(5, is hull consistent, with B'y^i denoting the Cartesian product 

B' where B'y is replaced by I. Box(2)-consistency is defined in the same man- 
ner with respect to box consistency. The computational cost of higher-order local 
consistencies is generally high, but the local gain in accuracy has been shown 
to outperform most existing techniques in several challenging problems (see, for 
example the circuit design problem in |l28p. 

4 Inner Approximations and Quantified Variables 

Interval constraint solvers based on the aforementioned techniques ensure com- 
pleteness of the computed results even for non-linear real constraints. However, 
soundness is not guaranteed while it is sometimes a strong requirement. Con- 
sider, for instance, a civil engineering problem [dOj such as floor design where 
retaining non-solution points may lead to a physically unfeasible structure. At 
the very best, present interval solvers can only assert that there exists at least 
one solution in every output box. 

As pointed out by Ward et al. E7| , one can distinguish several interpretations 
for a Cartesian product of variables’ domains B and a constraint system S: 

— only. All the solutions of S are included in B; 

— every. Every element of B is a solution of S; 

— some. There exists at least one solution of 5 in B; 

— none. The box B does not contain any solution of S. 

At present, interval constraint solvers only deal with the “some” interpre- 
tation, where the existence of at least one solution in the output box is not 
guaranteed, though. 

Furthermore, problems originating from sensor planning camera con- 
trol ESI, or control design P], not only require the output boxes to contain only 
solution points, but also that some input variables be universally quantified. 
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To date, constraint systems with universally/existentially quantified variables 
have mainly been handled by symbolic methods, among which one may single 
out Cylindrical Algebraic Decomposition (CAD) by Collins and Cylindrical 
Trigonometric Decomposition (CTD) by Pau and Schicho 12 til . Some numerical 
methods based on a bisection scheme also exist that solve constraint systems 
with universally quantified variables by computing an inner approximation of 
the underlying relation mm TT) . However, all these methods have strong re- 
quirements on the form of the constraints they process: for the most part, they 
are limited to polynomial constraints (except for CTD that handles trigonomet- 
ric polynomials, i.e. polynomials where occur cosine and sine functions involving 
variables not intermixed with algebraic variables); they are also limited to prob- 
lems with but few variables. 

We present in the following both problems that are beyond reach of present- 
day widespread interval constraint solvers: the computation of inner approxi- 
mations of real relations, and the handling of constraint systems with quanti- 
fied variables. Existing solving techniques — be they symbolic or numerical — are 
briefly surveyed, and some directions for extending interval constraint techniques 
to solve these problems are identified. 



4.1 Inner Approximation of Real Relations 

The notion of inner approximation of a real relation may be defined in some dif- 
ferent ways, depending on the intended application. The definition below relates 
the weak inner approximation of a relation to any box included in it that cannot 
be extended in any direction without including non-solution elements 133 - 

Definition 5 (Weak Inner approximation). Given a real relation p C R", 
let B = {B = Ii X • • • X /„ I R C p A Vj S {1, . . . ,n},V/' A : R x • • • x x 
Ij X Ij+i X • • • X /„ C p /' = /j}. The inner approximation lnneru,(p) of p is 
defined by: 



lnneru,(p) = Ri, with Bi G B 

A still weaker definition may be obtained by simply removing the maximality 
criterion [HEl- 

The notion of weak inner approximation is the one used by Shary as 
a computable subset of the united solution set (R 33 (A, b) = {a; G R” | 3A G 
A, 3b G b: Ax = b}), the tolerable solution set {S\/^{A,b) = {a; G R” | VA G 
A, 3b G b: Ax = 6}), and the controllable solution set {E^\/{A,b) = {a: G R" | 
Vb G b, 3A G A, : Ax = 6}) for a linear problem of the form Ax = b. The inner 
approximation for solving such a system is obtained by means of a specialized 
algorithm based on Kaucher arithmetic HH (/c,+,x), a completion of interval 
arithmetic with stronger properties (in particular, it is well known that (Ir,-|-) 
and (Ir, x) are only monoids; by contrast, (IC,+) and (/C, x) are groups). 
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More generally, weak inner approximations for relations, as defined by Def. 0 
(without the maximality criterion), may be mechanically computed by meth- 
ods based on non-standard interval arithmetics such as Kaucher arithmetic HP, 
Markov arithmetic m, and modal arithmetic 1241 . In particular, modal arith- 
metic is a tool that permits computing inner as well as outer approximations of 
the range of functions, while specifying the meaning associated to each interval 
(interpretation “some” or “every” ) . As for now, however, all these arithmetics 
are limited to (monotonic) rational functions. 

The preceding definition appears reasonable whenever the considered rela- 
tions are connected and there is no requirement for any representativeness of the 
computed sound solutions. On the other hand, one needs a stronger definition 
whevener representativeness is an issue: 

Definition 6 (Strong inner approximation). Given a real relation p C K", 
the strong inner approximation Inners(p) of p is defined by: 

Inners(p) = {r G R" | Hull({r}) C p} 

Given a constraint c and its associated relation pc, a simple method to com- 
pute an inner approximation of pc — in the sense of Def. 0 — included in some box 
B consists in testing with a method GlobSat() yet to be defined whether c is 



1 lnnerComputation(in: c, B G !”■ ; out: U G P(I")) 

2 begin 

3 sat c— GlobSat(c, B) 

4 case (sat) of 

5 true: 

6 return ({B}) 

7 false: 

8 return (0) 

9 unknown: 

10 if (StoppingCriterion(B)) then 

11 return (0) 

12 else 

13 (Bi, . . . , Bfc) ^ Split(B) 

k 

14 return ([J lnnerComputation(c, Bfe))) 

15 endif 

16 endcase 

17 end 

Alg. 2. General scheme to compute inner approximations by evaluation/splitting 

Function GlobSat() tests whether the constraint c is verified for all elements in Box B. Function 
StoppingCriterion() tests whether it is necessary/possible to split a box. Function Split() splits a box into k 
sub-boxes using some undefined strategy (e.g. bisecting the initial box along one of its non-canonical 
dimensions). 
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verified for any element of B; the result may be either true {pcC\B = B), false 
(there exists at least one element r in B such that -ic(r)), or unknown; in that 
case, it is necessary to split B and test recursively for the satisfiability of c on 
each resulting sub-box. This general method of evaluation/splitting is described 
by Alg.0 For systems of inequalities, the function GlobSat() may be implemented 
by straight evaluation of the expressions of the constraints over intervals, eval- 
uations by means of some special extension (Bernstein extension [114)1. or with 
some criterion on the existence of roots in a box, for polynomial constraints m)- 
However, the number of boxes to consider is clearly exponential in the worst case. 
Consequently, methods based on Alg.|2| cannot be used for problems with many 
variables and/or large domains. 



4.2 Solving Constraints with Quantified Variables 

As stated above, constraint systems with quantified variables are usually solved 
by computing quantifier-free equivalent systems by means of symbolic methods 
such as Cylindrical Algebraic Decomposition jTT) . 

We have seen that the solutions of some particular systems, such as linear 
systems of the form Ax = b, may be approximated by numerical methods, 
by computing inner approximations by means of tailored algorithms using non- 
standard interval arithmetics. These methods are still limited to particular form 
of constraint systems, though. 

On the other hand, some of the authors jS] have devised a general algorithm 
to compute inner approximations of real relations: relying on the properties of 
the constraint narrowing operators (see Section 0), the method computes sound 
boxes for constraints by applying complete CNOs to their negations. The method 
has also been extended to deal with constraint systems with one universally 
quantified constraint. 

The introduction of the aforementioned non-standard interval arithmetics 
into the framework of interval constraint solving appears promising for efficiently 
computing inner approximations of relations (that is, ensuring soundness of the 
results). The use of some extensions of algorithms such as the ones given in 0 
would then permit the devising of general-purpose methods to numerically solve 
constraint systems with quantified variables. 



5 Conclusion 

Interval constraint solving techniques have been shown to be very efficient to 
solve problems involving non-linear constraint systems of equations, when the 
desired solutions are punctual ones m- However, many problems do not fit in 
this framework: in simulation |3I, control design j2], robotics m and camera con- 
trol one is interested in regions of feasability, possibly with some quantified 
variables. 
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Consequently, a large range of applications cannot benefit from the effective- 
ness of present-day interval constraint solvers. Yet, interval constraint solving 
techniques may be extended in order to deal with these problems — and they 
already have, in a limited extent, as said in the previous section. 

Some directions for future research in order to broaden the spectrum of ap- 
plicability of interval constraint solving methods have been investigated in this 
paper. In particular, non-standard interval arithmetics such as Kaucher/Markov 
arithmetics and modal arithmetic seem promising tools in order to deal both 
with the computation of inner approximations and quantified variables. How- 
ever, their use will require the implementation of efficient libraries supporting 
them along with the devising of new interval algorithms. 
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Abstract. We present a high-level language for describing behaviors of 
autonomous agents in 3D virtual worlds, based on VRML (Virtual Reality 
Modeling Language). In order to describe agent behaviors, we have designed 
VRCC, a concurrent constraint programming language integrated in the VRML 
environment. The basis of this declarative language is the notion of constraint, 
and it is based on the Timed Concurrent Constraint framework, which 
integrates a discrete notion of time adequate for animation systems such as 
VRML. We illustrate this approach by some simple examples of virtual 
creatures that can autonomously move in the 3D world, and we describe some 
simple behaviors derived from biologically-inspired models of navigation. 



1. Introduction 

Our aim is to design a high-level language for describing behaviors of autonomous 
agents in 3D virtual worlds. The basis of this declarative language is the notion of 
constraint, which can be used to enforce hidden relations between agents and/or 
between an agent and the environment (e.g. minimal distances, non-collision, etc) or 
general integrity rules (such as gravity) and thus make sure that the simulated virtual 
world does not depart too much from the real one. 

A constraint is simply a logical relation between several unknowns, those 
unknowns being variables that should take values in some domain. A constraint thus 
restricts the degrees of freedom (possible values) the unknowns can take; it represents 
some partial information relating the objects of interest. The whole idea of constraint 
solving is to start reasoning and computing with partial information, ensuring the 
overall consistency and reducing as much as possible the domains of the unknowns. 
This is in sharp contrast to classical programming (either imperative, object-oriented 
or functional) where one only computes with complete values and has no support for 
propagating partial information. Constraint Programming has proved to be very 
successful for Problem Solving and Combinatorial Optimization applications, by 
combining the declarativity of a high-level language with the efficiency of specialized 
algorithms for constraint solving, borrowing sometimes techniques from Operations 
Research and Numerical Analysis [19]. We plan to use the power of constraint 
solving techniques, for developing complex and efficient planning modules for 
autonomous agents integrated in 3D virtual environments. 
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VRML (Virtual Reality Modeling Language) has become since a few years a de 
facto standard for publishing 3D scenes on the Web. It is a very interesting model 
because of its generality and versatility, see for instance [7] for a good introduction. 
Many plug-ins for Web browsers now exist for interpreting the VRML file format, and 
there is moreover an ISO normalisation of this language. However, VRML is more 
than a mere specification format for 3D scenes because one can specify complete 
virtual worlds in which the user can wander at will and where it can interact with 3D 
objects. More importantly, there is currently a growing interest in developing support 
for shared virtual worlds, which is putting the (virtual) reality of 3D digital 
communities at hand. Nevertheless, most of these shared virtual worlds suffer from an 
important drawback, namely they are not lively or interactive enough. As interaction 
is usually limited to chat with other users co-located in the same virtual world, the 
"interest" of a site depends more on the number of other people visiting it than on the 
originality or theme of its design. 

We will therefore consider in this paper the problem of populating such worlds 
with virtual agents representing life-like creatures which could autonomously 
navigate and react to their environment, and also possibly interact with users. 
Although this domain has been investigated for some years, see for instance [20], very 
few systems exist today and are indeed operational. As a first step in that direction, we 
will consider agents with simple adaptative behaviors inspired from research in the 
field of Artificial Life and robotics. For this purpose, we need to design a language in 
which to program such behaviors, and this language should be at the same time 
simple, declarative and powerful in order to make it possible to express a great variety 
of operations. We propose a framework based on VRCC, an integration within the 
VRML model of a timed Concurrent Constraint language. Moreover, in order to 
design autonomous, life-like 3D creatures that can autonomously move in the virtual 
world, we propose some simple behaviors derived from biologically-inspired models 
of navigation. A key point here is to consider situated agents, reactive to an unknown 
and constantly changing environment. The first example is motion planning for a 
virtual robot in a maze. The idea is to go to a point identified as a goal and to avoid 
obstacles. The agent is reactive and can thus take into account moving obstacles and 
goal. Secondly, we investigate exploration guided by a stimulus (e.g. light or smell) 
towards a goal (e.g. food), location of which is unknown, using either temporal 
difference or spatial difference methods. 



2. VRML 

VRML is a very interesting model because of its generality and versatility, see for 
instance [7] or [11] for a good introduction. Many browsers now exist for interpreting 
VRML format, which has now become a de facto standard for publishing 3D worlds 
on the Internet, and there is now an ISO normalisation of the language. VRML grew 
out of SGI's format for storing 3D scenes in Open Inventor, and was thus primarly 
designed to describe static 3D objects and scenes. VRML is based on the classical 
scene graph architecture for representing and grouping the 3D objects. Scenes can be 
constructed from built-in nodes (boxes, spheres, cone, or any polygon-shaped form) 
and new user-defined nodes can be also constructed using PROTO nodes. VRML 
provides basic light sources and performs basic scene illumination calculations. 
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VRML 2.0 [22] introduced primitives for animation and user interaction, based on a 
simple event model: each object in the virtual world can receive input events and send 
output events, these events are communicated between objects through predefined 
routes, completely independent of the structure of the scene graph. A VRML world 
basically consists of nodes, describing various shapes, in the scene graph and of a 
series of routes between objects. An important feature is the possibility to have script 
nodes, with associated Java or JavaScript programs, for treating and modifying 
events. 

VRML is based on a discrete time model, with special nodes called time sensors 
driving the animation. Such nodes are the only ones that can create output events 
without receiving inputs, based on some internal clocking signal. Time sensors, when 
active, run in cycles and generate ticks at the begining of each cycle, but they also 
generate events within a cycle stating which fraction of the cycle is currently 
completed. In order to be animated, objects have to receive events are regular 
intervals that will modify their position. The easisest way is to use interpolators that 
will, for given initial and final values and a given fraction of the cycle performed, 
compute a corresponding interpolation. For moving objects, only linear interpolation 
of trajectories is available as a primitive, more complex animation patterns have to be 
encoded by the programmer. 

The fact that time sensors generate fractional events within a cycle is the way of 
incorporating a continuous notion of time within the execution model. In theory such 
fraction_changed events are sent continuously to demanding objects. In practice they 
are generated only when needed, that is, when redrawing the scene because either the 
location, size or appearence of some object has been changed or because the viewer is 
moving and has therefore a different point of view. That is, the granularity of time is 
in practice, and not surprizingly, driven by the frame rate, which depends on the 
complexity of the scene, computing power of the machine and intrinseque speed of 
the browser. Anyway, considering 20 frames per second as a basic figure for real-time 
rendering, it means that events are send out in the VRML browser every 50 
milliseconds to drive the animation. Also note that the VRML model is such that the 
execution of script nodes is not interrupted, meaning that computations not fast 
enough will degrade the overall frame rate. 



3. Reactive Agents 

We will focus in this paper on the design of simple reactive agents in 3D virtual 
worlds. The paradigm of reactive agents has emerged in AI and robotics in the mid 
80's as a viable alternative to complex planning agents. Brooks' subsumption 
architecture and his seminal paper [5] has created, together with other researches, a 
new domain called "behavior-based" or "situated" robotics. To use the definition given 
by one of the pioneers of this approach [2]: « A reactive robotic system couples 
perception to action without the use of intervening abstract representation or time 
history ». Reactive agents are thus simple entities that receive percepts from their 
environment and can act on the environment by performing actions through some 
actuators, the simplest of which being to issue some motor command to effectively 
navigate in the external or virtual world. Reactive agents have no symbolic model of 
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the world they live in, but rather use sensory-action control loops in order to perform 
tasks in a robust manner. More details on this approach can be found in [6] or [16]. 

Let us consider the problem of designing a basic reactive agent in a VRML world, for 
instance an animated object than can avoid collision with other moving object that 
could be on his trajectory. Such a situation is depicted in figure 1, where a moving 
cone, oscillating repeatedly between the left and right sides of the chessboard has to 
avoid a box which could be put on its way. The box can be interactively dragged by 
the user and the cone has obviously to react in real-time and modify its trajectory 
accordingly. 

There is no support for this in the VRML model : collision avoidance primitives 
are only available for preventing the user to bump into walls or objects, and nothing is 
done for animated objects in the scene. We will use for this purpose the idea of spatial 
constraints, that is, to provide a mechanism that will enforce a logical relation to 
forbid an object to enter a specific portion of the scene. 




Fig. l.A moving cone and a box 

One thus need a very simple reactive planning module for giving to the moving cone 
in figure 1 the desired behavior : avoid the (user-draggable) box if it happens to be in 
the trajectory and go back to the initial trajectory as soon as possible. We implement 
the constraint by using a VRML Script Node linked, using routes, to both the moving 
obstacle (the box) and the moving object (the cone). It will be in charge of checking 
that the position of the object is always at a certain distance of the box and to modify 
the trajectory to avoid the obstacle either by the left or by the right, depending on the 
shortest. The graph of the routes linking the VRML objects is depicted in Figure 2. 
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The animation of the cone is given by a TimeSensor TS generating clock ticks that 
are routed to a standard (linear) position interpolator and then routed to the cone. A 
PlaneSensor PS listens to the position of the mouse controlled by the user and moves 
the obstacle (the box) accordingly. Both the potion of the box and the intended 
position of the cone are routed to the non-collision constraint, that is in charge of 
modifying the intended position of the cone to avoid the obstacle, the output of which 
is eventually routed to the cone. 




Fig. 2. The route graph of the basic reactive agent 

If we note by Object.X and Object.Z the (horizontal) coordinates of the cone and by 
obstacle.X and obstacle.Z that of the box, the arithmetic constraint to be enforced is 
(for a given radius) : 

(Object.X - Obstacle.Xf + (Object.Z - Obstacle. Zf > radius 

This constraint is checked for the temptative position of the object at each time point 
and if it not satisfied then the position is modified (by adding a small move 
perpendicular to the moving direction of the object either by the left or by the right) 
until the constraint is satisfied, in which case this value is taken as the new position of 
the object. One thus obtain a very natural motion for the object, and obstacle 
avoidance results in a circular trajectory around it. Obviously this scheme is reactive 
in the sense that it takes into account the fact that the obstacle can be moved by the 
user and the new induced constraint is checked in real-time to enforce an adequate 
trajectory for the object. 

However such a scheme is very limited, as it has to sequence the treatment of 
position constraints in order to finally route the output to the given agent. Therefore if 
one considers several position constraints that have to be satisfied together, such a 
scheme might be unsound as the output of the first constraint might be modified by 
the second one, and so on, leading eventually with an output inconsistent with some 
of the previous constraints. One thus has to design a more complex architecture, 
where navigation constraints are compositionally agglomerated, and solved together 
at the same time; we need a full programming language to specify animation and 
agent behaviors. 
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4. TCC as a Behavior Language 

In computer graphics and animation systems, the formalism which is the most 
commonly used to represent the behaviors of simple reactive agents is the finite state 
automaton (FSA). Many variants exist, such as the PatNets of [3], the Hierarchical 
FSA [8] or the parallel FSA [10]. Our approach rather considers that for representing 
complex life-like behaviors, one should not be restricted to some extended FSA 
formalism but rather needs the power of a complete programming language. The 
ability to handle states, variables, parameters, or recursion is indeed crucial. We have 
thus investigated the formalism of Concurrent Constraint Programming (CC) which is 
hot declarative, high-level and yet simple. We will detail in this section the design of 
VRCC, a concurrent constraint programming language integrated in the VRML 
environment. It is based on the Timed Concurrent Constraint framework of Saraswat 
etal. [18]. 



4.1 Concurrent Constraint Languages 

Concurrent Constraint Programming (CC) has been proposed a decade ago [17] as a 
new programming paradigm that can be seen as the merging and generalization of 
Constraint Logic Programming and Concurrent Logic Languages. 




Fig. 3. The Concurrent Constraint Model 

It makes it possible to combine both approaches, that is, on the one hand, the ability 
to reason (symbolically) and to compute (numerically) on specific domains 
(constraints) and, on the other hand, the possibility to have a dynamic data-driven 
control of the execution flow (concurrency). The fundamental idea of Concurrent 
Constraint Languages is the use of constraints for defining the synchronization and 
control mechanisms. Therefore, several agents could communicate and synchronize 
through a global store where all information is added in a monotonic way through the 
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time line. This paradigm is depicted in Figurre 3 : each agent can either add a new 
constraint (Tell operation) or check if some constraint is already true in the current 
store (Ask operation), i.e., from a logical point of view, implied by it. The Tell 
operation corresponds to the classical addition of a new constraint in Constraint 
Programming. Synchronization is achieved through a blocking Ask operation : if it 
cannot be stated whether the constraint is true or false in the current store, i.e. more 
information is needed to decide, then the asking agent is suspended until other 
concurrently running agents add (Tell) newconstraints strong enough to decide. The 
CC paradigm therefore breaks from the "problem solving" tradition of constraint 
programming (both CLP and CSP) based on transformational languages/models and 
opens towards a reactive framework for multi-agent languages based on constraints. 

4.2 Timed CC 

The Timed CC (TCC) extension of classical CC languages is the framework needed 
for integration within VRML. It basically introduces a notion of discrete time that is 
compatible with that of VRML (time sensors). The basic idea of TCC is that of 
synchronous programming exemplified by languages such as Esterel [4] : programs 
run and respond to signals intantaneously. Time is decomposed in discrete time 
points, generated by clocks outside the system and programs are executed between 
time-points. Program execution takes « zero time », that is, is neglectible w.r.t. the 
time clocking the overall system. Surprizing as it seems, this scheme, called the 
perfect synchrony hypothesis, is nevertheless adequate for modeling real-time systems 
and a language such as Esterel is indeed used to program low-level real-time 
controllers. In TCC, the concurrent computation of running agents is started at each 
time point and continues until quiescence of the computation. Control is then given 
back until another signal (time point) is generated. This mechanism is depicted in 
Figure 4 



4.3 Syntax of the Language 

At each time point, concurrent agents are running simultaneously until quiescenee and 
then the program moves to the next time-point. Basic actions performed by the agents 
are either posting a constraint to a shared store (Tell operation), suspend until some 



II \1 



time 




Fig. 4. The timed CC Model 
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constraint is entailed by the store (Ask operation), perform some method (Call 
operation), or post an action to be performed at the next time-point (Next operation). 
The syntax of these operations, in the classical algebraic CC style, is given below. We 
will use letters X,Y,...to denote program variables, letter A to denote an action and 
letter c to denote any constraint. 



tell(c) 


constraint addition 


ask(c) -> A 


synchronization 


A, A 


concurrent execution 


A +A 


indeterminism 


P(X,Y,...) 


agent creation 


3XA 


local variables 


next (A) 


temporal construct 



Observe that we will consider here the "-h" operation to represent one-step 
indeterminism (that is, an alternative might be selected only if it does not reduce to 
fail in one step) rather than the standard blind indeterminism. 



4.4 Goal Constraints 

With respect to classical operations of TCC depicted above, we need for designing our 
behavior description language a new operation ; Goal constraints are relations that the 
agent should try to achieve in the following time-steps if they are not satisfied at the 
current time-point. One thus need for each such constraint some solution-repair 
method that should eventually converge to a satisfiable state. The use of constraints as 
goals in order to describe behaviors is a simple and declarative way to specify 
animation of virtual creatures. Several goal constraints can be stated at the same time 
(e.g. non-collision with obstacles together with minimal distance w.r.t. a specific goal 
area) and solved together by the constraint solver. However this somewhat differs 
from classical constraint satisfaction techniques, where the constraint solver is in 
charge of finding an assignment of the variables of the problem in order to achieve a 
global solution. Indeed the outcome of a behavior could be considered as a sequence 
of actions that will eventually lead to the satisfaction of the goal, but not within a 
single time-step. Thus the reactive nature of behaviors naturally leads to consider 
reactive constraint solving techniques instead of classical (transformational) ones. We 
propose to use "iterative repair" methods in order to iteratively select actions that will 
eventually lead to the satisfaction of the goal constraints. This approach can be 
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implemented quite easily in the TCC framework, thanks to the next operation. The 
basic idea is to first define for each goal constraint a specific repair predicate that will 
be in charge of modifying (for the next time-point) the values of some of the variables 
appearing in the constraint in order to improve some given satisfaction criterion and 
to apply this repair iteratively until the constraint is satisfied. 

We could such roughly define this new operation (with a slight abuse of notation 
using constraint meta-calls and negation) as : 

Goal(C) :: ask(C) -> true, 

Ask(~C) ->( repair(C), next(goal(C) ) 

An alternative approach would be to design a new and dedicated solving method, 
derived from local search techniques [1] [23] suitably extended to handle constraint 
satisfaction problems. We are currently developing such a method, called "adaptive 
search". 

One has to observe that, with respect to a general planning module, the use of goal 
constraints restricts goals to be within the constraint domain proposed by the host 
language. It will thus be in general either numeric and symbolic constraints over finite 
domains, or arithmetic interval constraint over continuous domains, which are the two 
main domains for which efficient constraint solving techniques exist today [19]. Our 
framework could thus be seen as some kind of intermediate step between the pure 
reactive model proposed by behavior-based robotics, with no internal symbolic state 
whatsoever, and a full cognitive agent model as proposed by [9], which is based on a 
general goal-directed planning architecture and might be subject to performance 
problems when exploring a large search space. 



5. VRCC: TCC within VRML 

Let us now consider how to integrate the TCC framework within the VRML model in 
order to produce the VRCC language and execution model. 



5.1 Execution Model 

The main thing to handle in order to make TCC and VRML communicate is the 
treatment of time and the definition of synchronization at adequate time-points. We 
will therefore consider that VRML should clock the TCC system, i.e. that some 
TimeSensor node in VRML should send its clock ticks {events) for generating time 
points in the TCC part. This means that TCC computations should run between two 
events generated by a VRML time sensor node, that is, two frames drawn by the 
browser. The basic assumption here is that time is external and driven by VRML; 
there is no control over time in Timed CC. Concurrent computation of running agents 
is started at each time point (generated by VRML) and until quiescence of the 
computation. Control is then given back to VRML when quiescence is achived (that 
is, no agent can further be reduced), and so on. This architecture is depicted in Figure 
5, which shows the synchronization between VRML and TCC at each time-point. 
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Another important issue is to handle communication between the VRML world and 
TCC computations, i.e. more than a mere synchronization by clock ticks. This 
communication should be bi-directionnal : changes in the VRML world should affect 
TCC (that is, the TCC computation at the next time -point), and values resulting from 
TCC computations should be exported to VRML to be taken into account for the 
specified objects. This is done by handling two sets of shared variables : Eventins and 
EventOuts. 

Eventins are imported by TCC from VRML and constitute the initial constraint 
store (i.e. initial values) from which computation will proceed and EventOuts are 
exported from TCC to VRML and will be routed to VRML objects. Observe that in 
principle the two sets of variables could be distinct, but in general we will consider 
that they cover the same set of variables shared between VRML and TCC. 




Fig. 5. VRCC execution model 



5.2 Basic Properties of VRCC 

The first interesting property of VRCC computations is given by the underlying 
concurrency of TCC, both between agents and inside a single agent. Indeed, one can 
consider an agent composed of different sub-parts, with their own methods to perform 
animation, but which are linked together by some structural constraints. 

The second property of the execution model is reactivity : changes in VRML world 
are taken into account at each time -point and therefore behaviors (TCC computations) 
can react in real-time, or more precisely at the next time-point. One should therefore 
take care of avoiding to slowdown the system by heavy computations in the TCC part. 
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The third property is compositionality : because one has logical variables and 
constraints for programming behaviors in TCC, constraints can be accumulated by 
several agents (or sub-agents) to compositionally construct a single behavior. Several 
constraints for the same agent will be treated together in order to propose a global 
solution. 

Last but not least, the integration of constraint in the behavior language makes it 
possible to express problem solving capabilities: for instance a planner module, or 
scheduling of tasks, are easy to implement in a constraint-based language. 



5.3 Semantics of VRCC 

Let us give a simple interleaving operational semantics to VRCC, derived from the 
standard operational semantics of CC and TCC. We consider a VRCC program to be 
composed of a TCC program (i.e. a set of program clauses P and an initial state of 
agents to be run) and two sets of distinguished variables EventOuts and Eventins that 
will be used to communicate to and from VRML. Each configuration state of the 
transition system will be composed of three elements : 

C, the set of currently running agents, 

(T, the current constraint store, 

Y , the current set of agents to execute at the next time-point. 

The transitions will be decomposed in three groups : the basic CC rules, TCC rules 
(that is, the treatment of the next operation) and rules for communication between 
TCC and VRML. The operational behavior of VRML is not represented here but 
rather abstracted by two simple transitions rules that will modify the interface 
variables through two functions ImportFromVRML and ExportToVRML, which 
operate on substitutions on variables of Eventins and EventOuts respectively. 
ImportFromVRML is called by VRML when giving control to TCC and 
ExportToVRML is called at the end of the TCC execution and to give back control to 
VRML. 

The rules for communication between VRML and TCC are thus as follows : 

ImportFromVRML(0 = (X = v! X e Eventins)) 

<T;(j;y >h^< y;6;0 > 

<r;g;y >h/> 

ExportToVRML{0 ={X = v I X e EventOuts)) 



The rule for the next operation is defined as follows : 



< (next(A),T);(j;Y >h^< r;a;(/,A) > 
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Finally, the basic CC rules are as defined as usual, c.f. [17] (we do not give the 
rules for conjunction, disjunction and local variables, as they are straightforward) : 

3.p(Y)::A&P 

< {p{X),T)-a-r >^< (A,r);a vj{X=Y)-y> 

a U c ^ false 

< (fe//(c),r);a;7 >h^< F;a U c\y > 

a U c ^ false 

< (fe//(c),r);a;7 >h^ fail 

(J ^ c 

< (c ^ A,r);a ;7 >h^< (A,r);a;/ > 

a U c ^ false 

< (ask(c) A,r);a;7 >h^< T\g\y > 



6. A Classical Example : Nqueens as Intelligent Agents 

Let us take a well-known example in order to understand the behavior of intelligent 
agents in VRCC. We will consider the perennial N Queens problem which consists in 
placing 8 queens on a 8x8 chessboard in such a manner that no two queens attack 
each other. Only one kind of constraint will be used to prohibit two queens to be on 
the same row or diagonal : the disequation. Considering that there should be only one 
queen on each row, we will note Qi the queen on the ith row, and consider that the 
value of this variables is the number of the column on which it stands. We shall thus 
have for each couple of variables Qi and Qj : 

QJ ^ Qi , Qj ^ Qi + J-i,Qj^ Qi -J + i 

Although very classical in the constraint programming community, this problem is 
quite artificial and there exists many methods to efficiently solve it. We use it only to 
illustrate the idea of hidden relations (the above described disequations) constraining 
agents to move in order achieve a coherent state and we will focus on one particular 
point ; how to express the problem solving aspects as a multi-agent system where 
each queen is an autonomous agent moving on the chessboard and cooperating with 
others to find a solution. This is close in spirit to the work of [24], but will indeed 
give rise to a quite different model. Another aspect is important as we want to depict 
visually, as a 3D world, the solving process : when moving from one partial solution 
to another we are limited to physically feasible moves, that is, we cannot have queens 
randomly jumping from place to place, but only continuous moves from one position 
to another. The following figures depicts the initial and final states of the problem. 
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We have tried various alternative formulations of this problem, all following the same 
algorithmic shape : at each time point constraints are checked and if the overall 
position is not safe, unsafe queens will move to a new position. However, many 
variants can be implemented, depending on the communication allowed between 
agents in order to solve conflicts : 

1 . Without communication. Each queen move (either left or right) as soon as there is 
another one attacking her. This is not an efficient method which converges very 
slowly towards a solution. 

2. With limited communication : only between directly conflicting agents. When two 
queens are attacking each other, they localy solve the conflict by flipping a coin 
and only one of them moves to an adjacent square. Experiments shows that there is 
a high number of queens moving at each round - close to six - but a solution is 
found usually in a few thousands of moves. 

3. With full communication. In this case, only the most conflicting queen (that is, the 
one attacking the highest number of other queens) is moved at each time-point. 
Solutions are found quickly, typically in a few hundreds of moves. 

Eor the pure combinatorial problem solving aspects, experiments done with variants 
of the last method (without VRML visualization) showed that it is comparable or 
better in speed w.r.t. classical constraint solving methods (e.g. the GNU Prolog 
system), even for larger instances of the problem (with N up to several hundreds). 
This could be further improved, in considering that queens do not have to move to 
adjacent squares (either left or right), but could jump to any square on their row, by 
using the “min-conflict” heuristic, that is, choosing the square which minimizes the 
overall number of conflicts in the new configuration. 
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Fig. 6. One solution of the 8 queens problem 



7. Biologically-Inspired Creatures 

We have experimented with less trivial examples of autonomous agents, adapting 
from biologically-inspired models of navigation. There is currently a growing interest 
for such models both in the Artificial Life and the robotics community, as exemplified 
for instance by [15] or [20] which provide excellent surveys of recent researches. 

VRCC is a good language to describe such behaviors because its discrete notion of 
time corresponds to the basic cycle of a reactive agent that will modify his trajectory 
at each time-point w.r.t. a possibly changing environment. Thus we do not want to 
encode in VRCC a planning module that will compute some optimal trajectory and 
then drive the navigation of the creature to follow this path, but rather encode a step- 
by-step algorithm that will smoothly modify the navigation of the creature, 
"sampling" the environment time-point after time-point. Another aspect of VRCC, 
goal constraints, naturally fits the description of a goal-directed behavior as we will 
see in this section. It is nevertheless worth noticing that we will use only very simple 
goal constraints : an "attraction" constraint in order to direct the navigation towards a 
goal and a "repulsion" constraint to avoid obstacles. More complex combinations of 
goal constraints have to be investigated to study the real expressiveness of this 
language. 
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7.1 Obstacle Avoidance 

Our first example will be motion planning for a virtual robot in a room filled up with 
various obstacle, see figure 7 for a snapshot of the initial configuration of this 
problem. The idea is to go to a point identified as a goal (fhe sphere in the bottom 
right of the screen) and to avoid the brick-textured obstacles. 

Let us remark however, that this example is nevertheless a complex robot 
navigation problem with moving target goal and with moving obstacles, because both 
could be interactively dragged by the user in real-time. The agent is thus reactive and 
has to take any modification of the environment or target goal position into account. 

In this example avoidance constraints with respect to obstacles are used, in 
conjunction with a minimal distance constraint between the current position of the 
creature and that of the goal. 




Fig. 7. Initial configuration for obstacle avoidance 
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Fig. 10. Another trajectory 



7.2 Stimulus-Driven Search 

Biologists usually consider that the navigation system of small animals (rats and mice, 
etc) can be decomposed in two subsystems : one based on maps (called the locale 
system, as it is based on the recognition of locations linked in a graph-like manner), 
and the other based on routes (called the taxon system, for behavioral orientation). 
There seems to be evidences that the hippocampus is used to store the cognitive map 
for the locale system, cf. [14]. 

We will here only consider an agent with a very limited intelligence building no 
cognitive map but using only the taxon system for route navigation. The second 
example that we will consider is indeed an extension of the first one, where we will 
not give to the agent the location of the goal but rather use a exploration guided by a 
stimulus (e.g. smell) towards the goal (e.g. food), location of which is unknown. This 
exploration will be performed by using two different methods : temporal difference or 
spatial difference. The temporal difference method consists in considering a single 
sensor (e.g. the nose) and checking at every time-point the intensity of the stimulus. If 
the stimulus is increasing, then the agent continues in the same direction, otherwise 
the direction is changed randomly and so on so forth. This is exemplified for instance 
by the chemotaxis (reaction to a chemical stimulus) of the Caenorabditis Elegans, a 
small soil nemapode [13]. 
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Therefore the only constraint here is non-collision, that is, enforcing some minimal 
distance with respect to obstacles. However the creature will also have an additional 
operational (programmed) behavior that will be to check the input stimulus on its 
sensor at each time-step and to change direction if necessary. Again, as in the 
previous obstacle avoidance example, the source of the stimulus and the obstacle can 
be moved interactively in real-time and the agent has to react accordingly. 

Figures 1 1 and 12 depict the top and side views of the initial setting. Observe that the 
corridor between the two obstacles is not large enough for the creature to pass through 
and thus a detour will be needed. The source of the stimulus (“smell”) is the cylinder 
on the right-hand side (representing a birthday cake). 

The resulting trajectories of the creature on two different runs of this experiment are 
depicted on figures 13 and 14, showing that the agent performs not so bad, i.e. it 
eventually reach the source of the stimulus, although it does not perform a direct 
trajectory and might wander in some irrelevant regions of the environment. 




Fig. 11. Top view of the initial configuration 
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Fig. 14. Temporal difference method (2) 



A more efficient strategy is possible by using the spatial difference method. It requires 
to have two identical sensing organs, placed at slightly different positions on the agent 
(e.g. the two ears). The basic idea is to favor motion in the direction of the sensor that 
receive the most important stimulus, as in the well-known sensory-motor coupling in 
robotics. This behavior gives very good results, and the agents goes directly towards 
the source of the stimulus, see the corresponding trajectory depicted on figure 15. 
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Fig. 15. Spatial difference method 

More complex strategies are possible, e.g. by considering more sensors or by 
combining the temporal difference of several sensors, but they are not really more 
effective than the basic spatial difference method [12]. 



8. Conclusion 

We have presented a high-level language for describing behaviors of autonomous 
agents in virtual environments. We use VRML for the 3D visualization part and a 
timed concurrent constraint programming (TCC) for agent programming. This 
framework seems well-suited for animating simple 3D autonomous creatures. 
Interesting behaviors such as obstacle avoidance or stimulus-driven exploration 
towards a source (gradient-following) are easily expressible in this system and opens 
up for a variety of biologically-inspired behaviors. 
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Abstract. Constraint logic programming (CLP) is a multidisciplinary 
research area which can be located between Artificial Intelligence, Ope- 
ration Research, and Programming Languages, and has to do with mode- 
ling, solving, and programming real-life problems which can be described 
as a set of statements (the constraints) which describe some relationship 
between the problem’s variables. This survey paper gives a brief intro- 
duction to C(L)P, presents a (necessarily partial) state of the art in CLP 
research and applications, points out some promising directions for future 
applications, and discusses how to cope with current research challenges. 



1 Introduction and Main Concepts 

In the last 10-15 years. Constraint Logic Programming (CLP) has evolved from 
a basic research idea to a powerful programming paradigm that is increasingly 
used to model and solve many hard real-life problems. Several companies have 
started to exploit this technology, and the number of industrial applications is 
now growing very quickly. Also the ACM has recently recognized the power of 
CLP, by listing it in 1996 among one of the few areas of Computing Science 
which are classified as “strategic directions” |S3|. 

A recent review inni of an introductory book on CLP succeeds in our 
view to describe the essence of constraint programming: 

One of the most important tasks of a programmer is to transform the 
functional specifications of a program into a language code that closely 
reflects the underlying physical architecture of the computer. In this pro- 
cess, he or she has to define objects and procedures that correspond to 
entities and operations in the application domain, then explicitly main- 
tain relationships among programmer-defined entities, and finally find 
objects that satisfy them. 

* Other contributing authors: Frederic Benhamou, Manuel Hermenegildo, Frangois Pa- 
chet, Helmut Simonis, Thomas Sjoland, Mark Wallace. These authors have provided 
a lot of useful material for the generation of this survey. 
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Suppose you are tired of such tedious work. You want simply to state 
relationships between objects and ask your assistant (a program) to en- 
sure that these relationships are maintained. You have then upgraded 
yourself from a traditional programmer to a constraint programmer. 

In fact, constraint programs are highly declarative, and allow to describe 
many real problems by using constraints, that is, statements which pose some 
relation among the problem’s variables. Such a way of specifying problems can be 
introduced in many traditional programming environments, but the best match 
is found when using a declarative programming paradigm like Logic Program- 
ming (LP) which is also based on relations. 

More precisely, each constraint specifies a relation among a subset of the 
objects of the problem, where each object has a set of possible values. Thus 
a constraint restricts the space of possibilities for such objects. For example, 
in the description of an electric circuit, a typical constraint is that “the sum of 
currents flowing into a node must be zero” . Or, in the problem of assigning offices 
to employers, one can have the constraint that “Mary and John must share an 
office, but John and Susan must have different offices” . Or also, in a graphical 
interface system, one may want that “two graphical objects never overlap” . 

The description of a problem as a set of constraints is very declarative: it 
just says “what” has to hold, not “how” to make it hold. Many (partial or 
complete) solution techniques have been developed with the aim to find one 
or more solutions for a constraint problem, that is, assignments of variables to 
values such that all constraints are satisfied. The most widely known and used 
complete solution technique is based on assigning a value to each variable at 
a time, while satisfying all constraints involved in the assigned variables, until 
either all variables are assigned to a value (thus we have a solution), or there 
is some variable which cannot be assigned, in which case the search returns to 
a previous decision and chooses an alternative value for one of the variables. 
This method to search for a solution, usually called backtracking search, may 
in general explore the whole tree of possibilities before finding a solution, or 
discovering that there is none. 

Many incomplete solution techniques have been developed to help back- 
tracking search to have a better performance. Most of them are based on the 
concept of constraint propagation, which has to do with the possibility of using 
the information given by some constraints to infer necessary conditions over the 
constraints’ variables. Moreover, such conditions can in turn help to deduce fur- 
ther consequences on other constraints, and so on. In this way, information is 
propagated among constraints passing through the shared variables. Assume for 
example to have a graphical layout system, where, for any two graphical objects, 
we have the constraint that they cannot overlap. Suppose now that we use the 
mouse to move one of the graphical objects in an area where there are already 
others objects. Then, by constraint propagation, such objects will be moved to 
free areas, or, if there is no free area which is big enough for them, possibly many 
objects will be moved around in the screen to reach a situation where no two 
objects overlap. Constraint propagation was initially used in the 70’s for scene- 
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labeling applications |185ll89j . but since then it has been extended and adapted 
to many other contexts, producing a high number of propagation algorithms, 
the most influential being Many constraint systems 

have been developed: each one has one or more constraint classes in mind, and 
for those classes it provides both complete and incomplete solution algorithms, 
usually combined together. Examples of classes of constraints that have been 
considered and for which efflcient propagation and solving techniques have been 
built are finite domain constraints, arithmetic constraints, linear constraints, 
boolean constraints, and interval constraints. 

Being able to model and solve a real-life problem with the available con- 
straint classes and solving techniques may seem enough, but in fact in most 
cases the possibility to directly control both the search and the propagation 
may be crucial. In fact, one may want to choose the propagation technique on 
the fly, depending on the particular application, and also to control how the 
search tree is explored. For this reason, usually constraint systems (providing 
some built-in propagation and solution algorithms) are embedded into a high- 
level programming environment, which allows to have the desired control. The 
fact that both constraint systems and logic programming im are declarative 
frameworks based on relations and backtracking search made their marriage 
easier and more natural. More precisely, when it became clear that term uni- 
fication was just a special form of constraint satisfaction, LP was generalized 
by replacing terms with constraints, and unification with a suitable constraint 
handling system. The resulting programming paradigm, called Constraint Lo- 
gic Programming (CLP), has been the basis (not necessarily syntactically) for 
many commercially successful systems which model and solve real-life problems 
by using the constraint (logic programming) technology. In particular, CHIP 
was the first CLP language to employ constraint propagation [SB|- Other 
examples of CLP-related systems are the constraint handling libraries of ILOG 
[IlDlIj and COSYTEC and the CLP languages Prolog III |48l4tij . and Prolog 
IV PIEI, CLP(R) pun], ECLiPSe IdOlillHVj . CIAO jS0|, and clp(fd) pni- With 
these systems, many hard application domains have been tackled successfully 
using constraint-related technologies. Examples are circuit verification, schedu- 
ling, resource allocation, timetabling, control systems, graphical interfaces, and 
many combinatorial problems [ElHHl. 

The presence of constraints within a language is useful in many respects. 
In fact, the direct representation of a problem in terms of constraints results 
in short and simple programs. Moreover, the embedding of constraint-based 
techniques into a high-level language gives the right level of abstraction for the 
programmer, who can concentrate on choosing the best technique combination 
for the problem at hand. Also, since programs can be quickly developed and 
modified, it is possible to experiment with various ways of solving a problem 
until the best and fastest program is found. 

While the birth of CLP languages was based on the observation that con- 
straints could be used to model real-life statements better than term equalities, 
and also to control the search for a solution, another generalization came to 
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life when it became evident that constraints could also be used to naturally 
model agents’ communication and synchronization in concurrent systems. In 
fact, agents can communicate by posting constraints on shared variables, and 
can synchronize by checking whether a certain constraint has been posted by 
some other agent. This observation was the main idea underlying the concurrent 
constraint (CC) programming framework |ltil| . which posed the theoretical fo- 
undations for the birth of other concrete languages, like AKL [851137111!^) and 
Oz 



which can model reactive and distributed systems via CLP- 

related technology. 

The rest of this survey paper is organized as follows. First we will describe 
the state of the art in constraint-related research in Section and then we 
will attempt to give an overview of the current scenario for constraint-based 
applications in Section 0 In Section 0 we will discuss the relationship between 
theoretical research and application work, by looking at the proceedings of the 
CP conferences, and in Section 0 we will report on the results of a questionnaire 
concerning CP-related applications. Then, in Section 0 we will point out some 
directions for future opportunities in applications using constraints, both in cur- 
rently considered domains and also in new ones, and in Section Q we will discuss 
some current challenges for constraint-related research. 

This chapter does not provide a complete scenario of the applications of 
CLP, nor of the research results related to CLP. One of the reasons is that a 
complete list covering all aspects of CLP research and applications could easily 
fill several books. However, both the incompleteness and any other drawback 
of this paper should be attributed to the main author, who did her best but 
could not avoid, among other faults, following a bias towards more familiar 
issues. Nevertheless, fortunately many other survey papers on CLP are present 
in the current literature as well as introductory papers |E3 and books 

[1 1 31 a 1 4.81881 1 til )l I 1 82] . Thus the reader may refer to such sources to fill the gaps 
of this survey. 



2 Research in CLP: State of the Art and Analysis 



The state of the art in CLP research and application is mainly reported in the 
proceedings of the annual international conference on Principles and Practice 
of Constraint Programming (CP) fl 3tiitifif1 7fif1 281 1 l)4j and of the conference on 
Practical Applications of Constraint Technology (PACT/PACLP) [183,185,186, 
138,122] and also in the recently established CONSTRAINTS journal by Kluwer 
Academic Publishers. Other related conferences and journals also report work on 
CLP, mainly those in areas like Artificial Intelligence (Joint International Con- 
ference on AI ~ IJCAI, Conference of the American Association for AI - AAAI, 
European Conference on AI - ECAI, The AI Journal), Logic programming (In- 
ternational Logic Programming Symposium - ILPS, International Conference 
on Logic Programming - ICLP, Journal of Logic Programming), Databases, and 
Operation Research. 
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In this section we will briefly describe some of the main areas of research 
related to CLP. Notice that some research work concerns more than one of the 
areas listed below. As an example, constraint propagation has to do with finite 
domain constraint solving, but it is used also in constraint programming] in these 
cases, we have chosen to describe it within the area which is more central to the 
work (in the above example, constraint solving). 

Finite domain constraint solving. The origins of finite domain constraints are 
to be found in Artificial Intelligence (AI), where finite domain constraints were 
first introduced and constraint propagation was used to solve picture processing 
problems since the 70’s Many research efforts still lie in the AI area. 

Since solving a finite domain constraint system is an NP-hard problem, much 
work has focussed on the identification of tractable classes of constraint problems, 
that can be solved in polynomial time (see 1120112711821 for an overview of many 
algorithms). Such classes are usually identifled by a precise graph structure (like 
a tree jt)7ll5t)l5;lj l or by a precise combination of algebraic operators fl Id) . Re- 
cently, graph decomposition strategies and constraint propagation techniques 
have been used also for continuous constraint problems j2,4l I . and for pro- 
blems where constraints represent differential equations m- For some classes 
of constraint problems, it has also been recognized that enforcing a low level of 
constraint propagation guarantees a backtrack-free search IS3. Recently, most 
of the graph decomposition method for constraint problems have been compa- 
red, and the results suggested that the best method is based on the concept of 
hypertree decomposition, developed in database theory P^ . 

The concept of a constraint language has recently been carefully formalized, 
so that its expressive power can be studied and it can be told if constraint pro- 
blems expressed in a certain language are tractable[110, 111, 112, 113, 103,41, 114, 
109]. 



For both tractable and non-tractable constraint problems, it is crucial that 
the backtrack search process performs as good as possible. For this reason, much 
work has been devoted to study several heuristics which may influence the be- 
havior of the search engine, like the variable and value orders PH! and also the 
amount and kind of look-ahead to perform at each step PH- 

Another issue that has received great attention recently is the possibility of 
locating the “really hard” problems. It turns out that when constraint problems 
are generated randomly, for example to evaluate the behavior of a new algo- 
rithm, most of the generated problems are easy. Thus, special care is needed to 
make the random generators produce non-trivial problems. It has been recently 
demonstrated that for many random generators there is a phase transition from 
easy to hard problems, and that hard problems are located where only few solu- 
tions exists |84llVbll4V| . Current on-going work is mainly concerned with finding 
new transition phases (for new algorithms, or new classes of constraint problems) 
testing new algorithms on hard problems, and evaluating the power of the 
random model 0121. 



Programming with Finite Domain Constraints. Many CLP languages have been 
built to deal with finite domain constraints. The main examples are CHIP PI, 





Constraint (Logic) Programming: A Survey on Research and Applications 



45 



Eclipse jlOOI187) and clp(fd) gSI- These languages have a wide applicability, and 
raise a number of important research issues. 



Much work on finite domain CLP is centered on the introduction of global 
constraints. The notion of a global constraint is basically as follows: there are 
cases in which having one bigger constraint (bigger in the sense of the number 
of its variables) may be better with respect to a set of smaller constraints. A 
typical example concerns a set of disequality constraints, which seldom give rise 
to useful constraint propagation. In such cases, it may be necessary to perform 
a complete search among the domains of all the variables to find one solution. 
This useless expensive search can be avoided by using a constraint called alldif- 
ferent which connects all the variables. In fact, by using this one constraint, the 
problem of finding a solution can be reformulated as a bi-partite matching pro- 
blem between variables and values and classical graph algorithms can be applied, 
which can help to derive enough information to reduce the search. In general, 
the introduction of global constraints works as follows: instead of expressing a 
problem by many primitive binary constraints, we describe it with a few global 
constraints on sets of variables. In this way, we can model problems in an easier 
way, we have a smaller number of constraints, and more sophisticated and effi- 
cient algorithms can be used. However, global constraints should not be created 
ad hoc for each application, but should be general enough to be used in many 
applications. Typical examples are the alldifferent constraint cited above, the 
atmost constraint, which sets a limit on the number of variables with a certain 
value, and the cumulative constraint. 



Languages like CHIP |SH| have a complex global constraint morphology in- 
cluding the above and many other global constraints H2|. Other languages, like 
Sicstus Prolog Eclipse [11)1)11 8Yj . IF Prolog, and Oz [94liyyi8t)l98j include 
variants of some of the global constraints used in CHIP. 



As noted above, when introducing new global constraints, one has also to 
provide efficient handling mechanisms for them. An example is the filtering al- 
gorithm proposed in uni for global sequencing constraints, and used for difficult 
car sequencing problems. Other studies on the use of constraint propagation over 
global constraints (in particular, the alldifferent constraint) show the practical 
value of using this kind of constraints |1 6611 5n| . Global constraints have been 
recently used also for partial constraint satisfaction problems, where some con- 
straints must be violated to find a solution, showing a big potential for an efficient 
handling of such problems 0. 

As said in the introduction, one of the main advantages in embedding a con- 
straint system within a CLP language is that we can control the search process. 
In the last few years, the use of partial search techniques has significantly impro- 
ved search methods. Partial search techniques limit the number of alternatives 
explored in different nodes of the search tree. In this way, the usual depth-first 
backtracking search used in CLP, which sometimes explores only a small por- 
tion of the search tree, can be replaced by other search schemes (like LDS jS2] or 
credit-based search E!) which can consider many different paths in the search 
tree, without much implementation overhead. 
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Dynamic constraint problems are constraint problems which change over 
time, by either the addition or the deletion of some constraints, or a combination 
of these two operations. While constraint addition is what usually is modeled at 
each computation step of a CLP program, constraint retraction is seldom con- 
sidered, although it would be very useful in many scenarios, like for interactive 
or dynamic systems. For this reason, some effort has been devoted to embed the 
notion of constraint retraction, and also some efficient algorithms to accomplish 
it, within classical CLP languages. For example, the clp(fd) programming fra- 
mework has recently been extended with both a syntax, a semantics, and some 
efficient methods to handle the possibility of retracting a constraint m- Notice 
that constraint retraction allows also the modeling of hypothetical and interac- 
tive reasoning. Another aspect of dynamic constraint problems is that, once a 
solution is found, there may be changes which invalidate such a solution. This 
problem can be addressed either by developing efficient ways to find a new solu- 
tion from the old one, or by generating stable solutions, that is, solutions which 
are more likely to remain as such even after a certain class of changes m 

Non-linear constraints. The possibility to handle and solve non-linear constraints 
over real numbers is important for many areas (like economics, mechanics, en- 
gineering, . . . ) . Problems involving such constraints are usually very expensive 
computationally, thus it is often hard to ensure termination and to guarantee 
finding all solutions. Beside classical techniques, now many tools use interval me- 
thods for solving this kind of problems. Also for this reason, interval constraints 
have been introduced in many CLP languages, like ECLiPSe jlUUIlSYIlt)Uj and 
CLP(BNR) particular, both the Helios language and Numerica ^Q] 

have been designed appositely to solve non-linear constraint systems using inter- 
val analysis algorithms, which combine techniques from numerical analysis and 
artificial intelligence. These languages allow to state many nonlinear applications 
in a very high-level formulation, thus letting the user focus on modeling aspects 
instead of low-level details, and have been shown to outperform traditional con- 
straint solving methods and interval algorithms on many constraint-solving and 
global optimization benchmarks. 

A special issue of the Constraints journal has been devoted to the subject of 
interval constraints m- 

Modeling. It is very important to have a good modeling language to express con- 
straint problems. At the moment, most constraint systems are either extensions 
of a declarative programming language (like Prolog) or libraries used together 
with conventional programming languages (like C or C-|— k). Currently there is a 
lot of work in trying to introduce constraint modeling languages that make the 
modeling phase easier and more natural (already cited examples are Helios |8hj . 
Numerica and OPL |H2|)- Some of these languages make use of visual tools 
to describe and generate constraint programs. 

For example, in the FORWARD refinery scheduling system [JHli which uses 
a graphical specification tool for CHIP nzm, the model of a refinery is entered 
via a graphical drawing tool and the constraint model is generated from the 
layout. CML is a constraint modeling language which has been developed for 
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facilitating the tasks of stating and modifying combinatorial problems 0: CML 
problem specifications allow for constraint formulations that reflect natural lan- 
guage expressions, and that are then translated into efficient CHIP programs. 
Another recently developed modeling language is VISUAL SOLVER El, which 
allows to specify both the problem statement and the heuristics to be used to 
And solutions. 

Other recent approaches to modeling a real problem as a constraint problem 
use techniques related to negotiation: the constraint solver interacts with a hu- 
man providing partial solutions (suggestions) based on partial knowledge, and 
gaining further information about the problem from the human through his/her 
evaluation of the suggestions m- Besides negotiation, also other techniques, 
which have not been familiar to the constraint community so far, have been 
used to help the user in the modeling phase. An example is the use of machine 
learning techniques: in the context of soft constraints (see later), the user provi- 
des the system with some examples of solutions ratings, and the system learns 
the whole constraint problem |EZ|. In this way, and also by using an incremen- 
tal acquisition/learning technique, the task of modeling a real life problem as a 
(soft) constraint problem is greatly simplified. 

Another interesting modeling framework is also the one based on Abductive 
Constraint Logic Programming (ACLP) (see http : //www . cs . ucy . ac . cy/ aclp/), 
which has been built on top of ECLiPSe UDDI. ACLP has been originally moti- 
vated by the need to make abduction more efficient. But it has also been studied 
as a high-level declarative modeling environment that can exploit the lower-level 
constraint solving capabilities of the CLP language on which it is built, aiming 
at a balance of flexibility (under problem changes) and efficiency. 

Debugging. One common problem for users of the CLP systems in use is the 
sometimes unpredictable behavior of the constraint model: even small changes 
in a program or in the data can lead to a dramatic change in the performance. 
This is because the process of performance debugging, designing and improving 
constraint programs for a stable execution over a variety of input data, is cur- 
rently not well understood. Related to this problem is the long learning curve 
that novices experience. While simple applications can be built almost imme- 
diately, it can take a long time to become familiar with the full power of a 
constraint system. One attempt to solve these problems considers the possibility 
of visualizing the search tree |32|. Tools like the Oz Explorer [1 b4] . the CHIP 
search tree tool H2I], or the system recently developed within the CIAO system 
m, which provides a 3D visualization via VRML imi, allow a much deeper 
understanding of the search process, since they provide enough information to 
analyze propagation and the state of the variable domains at each node of the 
tree. A general and comprehensive approach to CLP debugging has been taken 
within the DiSCiPl European research project (22532), where several tools have 
been developed to help the programmer during all phases of development of a 
constraint program. Such tools are used for static analysis, for error diagnosis, 
for search space analysis and for constraint propagation analysis: no single tool is 
powerful enough, but their combination makes them effective enough to provide 
a good debugging environment. 
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Soft constraints. By developing real applications, it has increasingly become clear 
that finite domain constraints were not enough to model faithfully a real problem. 
The main problem is that real problems usually cannot be simply described by 
a set of true/false statements, like classical constraints are, because they have 
features like preferences, probabilities, costs, and uncertainties. Also, many real 
problems, even when they are correctly modeled, usually are overconstrained 
unzi: the user puts so many constraints that it is impossible to satisfy all of 
them. In these cases, we first have to find out that there are no solutions (and it 
may take a long time to do this), and then we have to decide which constraints 
to relax so as to make the problem soluble. For these reasons, the concept of soft 
constraint was introduced: a soft constraint is just a constraint plus an additional 
element, which can be interpreted as a cost, or a level of importance, or a degree 
of uncertainty, or a similar criterion. Then, finding a solution does not mean any 
longer to find a way to satisfy all constraints, but to obtain an assignment of the 
variables to values which has the “best” value for the chosen criterion. Research 
in this area first started with the hierarchical CLP (HCLP) system |2ni, a CLP 
language where each constraint has a level of importance and a solution of a 
constraint problem is found by respecting the hierarchy of constraints. Then 
much work on fuzzy constraints, where each constraint has associated a value 
between 0 and 1 and we have to maximize the minimum of such values, has been 
done to formalize the new framework and study efficient solution algorithms 
for it |60ll58l62ll62| . A combination of constraint hierarchies and fuzziness has 
also been used m- Overconstrained problems have also been tackled using 
the notion of partial constraint satisfaction, where a metric was added to the 
constraint problem to help produce a solution that satisfied as many constraints 
as possible [HH). 

Lately some theoretical work has focussed on the development of more gene- 
ral frameworks for soft constraints, like the semiring -based formalism EEEDI, 
where each tuple in each constraint has an associated element taken from a se- 
miring, and the valued constraint formalism, where each constraint is associated 
to an element from a totally ordered set [ I ti.'tpf) 1 1,'IDj . For such general formalisms, 
the main efforts are in trying to extend and adapt the propagation and solution 
techniques typically used for classical finite domain constraints, and to study 
their properties. Recently, the finite domain CLP language clp(fd) [301 has been 
extended to handle semiring-based constraints, obtaining a language paradigm 
called clp(fd,S) [ZS| where S is any semiring, chosen by the user. By choosing one 
particular semiring, the user decides to use a specific class of soft constraints: 
fuzzy, or optimized, or probabilistic, or even classical hard constraints. For va- 
lued constraints, we do not have yet full CLP languages working with them, 
but we have many techniques to achieve good lower bounds for their optimal 
solutions, which in most real cases seem to be good enough EEg. 



Constraint query languages. As noted above, constraints are just relations, thus 
it is obvious that many researchers have investigated the relationship between 
CLP technology and Databases (DB). In this area of research, there are mainly 
two ways in which constraints and databases have interacted so far. On one side. 
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results on DB (for example, on decomposition and information derivation) have 
been generalized and adapted to constraint problems, generating useful tools to 
test the tractability of some classes of constraint problems and efficiently solve 
such classes mm . On the other hand, classical query languages in DB have been 
extended to deal with constraints, which are used not only to specify integrity 
information, but also as a mean to represent in a compact way a possibly infinite 
set of DB tuples. In fact, a relational tuple can be seen as a particular type of 
constraint: a conjunction of equality constraints between attributes of the tuple 
and values from a given domain. The introduction of new logical theories to 
express relationships (that is, constraints) between the attributes of a DB item 
lead to the definition of Constraint Databases as a new and interesting research 
area !TTT^ . 

Constraints have been added to relational DBs at different levels. At the data 
level, constraints may represent generalized tuples that are able to specify pos- 
sibly infinite sets of tuples. In this sense, for example, constraints are a powerful 
mechanism to model spatial and temporal concepts that arise in DBs, where 
often infinite information has to be represented PE21. 

To deal with constraints, both the relational calculus and the relational alge- 
bra of classical DBs have been extended |iiVlil8l80| . leading to new and more 
expressive query languages for which many properties are being studied. An ex- 
ample of such languages is obtained by adding linear constraints to Datalog, 
which has been studied in Una. Other examples are safe stratified Datalog, con- 
sidered in and the integration of linear constraints with DBs, for which 

query optimization has been studied in m- Query optimization has also been 
studied in CHOI in the context of deductive queries over constraint DBs. 



Concurrent and distributed systems. The use of constraints in modeling the be- 
havior of concurrent systems has started with the development of the concurrent 
constraint (CC) programming framework, where concurrent agents share a store 
of constraints where they may either post some more constraints (tell opera- 
tion), to communicate with the other agents, or ask whether some constraint is 
already present (ask operation), to synchronize with the other agents. We al- 
ready said in the introduction that some real languages, like Oz ID4ll77IHbBlHI . 
AKL jiS5f I DiSf iTTj . CHR [Z2|, and CIAO have taken up this model and 
implemented it (although each one differently), thus providing a programming 
framework for concurrent systems. 

Recently much research effort has tried to extend this model to consider also 
distributed systems, where the store is not shared by all agents but is rather a 
collection of local stores, and also software mobility, like that present in web- 
based agent systems. In this respect, both languages and new solution algorithms 
have been proposed, by adapting existing techniques to a distributed context (for 
example in USD). Another line of extension of the CC framework is concerned 
with the introduction of time, in order to be able to model and program real-time 
applications m- 

One of the advantages of the languages based on the CC framework is that, 
via the ask operation, it is possible to describe within the language many algo- 
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rithms or techniques (like constraint propagation methods) which in sequential 
CLP languages have to be provided by the system. This added flexibility is used 
for example in the language Oz, where the programmer has all the necessary 
tools to program his/her own inference engines 

Comparison/combination of various techniques. Some of the real problems that 
are currently solved by using CLP technologies can also be solved by Operation 
Research (OR) techniques, with complementary advantages: CLP offers genera- 
lity, flexibility, a high-level modeling environment, search control, compactness of 
the problem representation, constraint propagation, and fast methods to achieve 
a good solution, while OR is sometimes the only way to And the optimal solu- 
tion. Therefore, it seems a good idea to try to get the best from these two 
kinds of technologies, by building systems which can use both of them to solve 
a problem. This approach has been used already in some systems, like the 2LP 
system unim], as well as in m. which uses this combined approach for speci- 
fic telecommunication problems. Moreover, several workshops have focussed on 
the integration of CP, OR and AI technologies. However, we still need a lot of 
work to fully exploit the potential of the interaction/integration of such different 
technologies. 

3 CLP Applications: State of the Art and Analysis 

In this section we will give an overview of the main application domains in which 
CLP technology has been applied and has shown to be competitive both in terms 
of modeling flexibility and solution efficiency. As in the previous section, we have 
structured this overview by listing the main application domains; however, in 
most cases a CLP application has aspects related to several domains. In these 
cases, we have chosen to describe it within the domain which is closer to the main 
aim of the application. As for the research overview, also this application survey 
is far from being complete, although we believe that most of the main application 
domains are represented here. A good survey paper on CLP applications, from 
which we took many useful points and insights, is CHI. 

Assignment problems. Assignment problems were one of the first type of indu- 
strial applications that were solved with the CLP technology. These problems 
usually have to handle two types of resources, and constraints among them, and 
try to assign one resource of the first kind to one of the second kind such that 
all constraints are satisfied. 

An example is the stand allocation for airports, where aircrafts (the first 
kind of resources) must be parked on the available stands (the second kind of 
resources) during their stay at the airport. The first industrial CLP application 
was developed for the HIT container harbor in Hong Kong [114,'-!) . using the 
language CHIP: the objective was to allocate berths to container ships in the 
harbor, in such a way that resources and stacking space for the containers is 
available. Other Hong Kong applications are at the airport, where a CHIP- 
based system is used to solve the counter allocation problem and another 
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constraint-based system, which uses the ILOG libraries, is used for the stand 
allocation problem since mid-1998 m Another system, called APACHE m, 
was a demonstrator for stand allocation at Roissy airport in Paris: the objective 
was to replan the allocation when a change of arrival/departure times occurred. 
Personnel assignment. Personnel assignment problems are a special case of as- 
signment problems where one resource type consists of humans. This peculiarity 
makes them specific enough to be considered separately. In fact, changing work 
rules and regulations impose difficult constraints which evolve over time. Also, 
user preferences often lead to over-constrained problems, which have no solution 
satisfying all constraints. Another important aspect is the requirement to balance 
the work among different persons, which leads to hard optimization problems. 

The Gymnaste system m produces rosters for nurses in hospitals, and is 
used in many hospitals in France. Around 250 technicians and journalists of 
the French TV and radio station RFO are scheduled with the OPTI-SERVIGE 
system ra, which generates weekly workplans from the individual activities 
which must be covered by different persons with different qualifications. The 
personnel for the TGV high-speed train bar and restaurant services is scheduled 
with the EPPER application m-- all services for a month are covered by a 
team of 250 people. Recently a distributed GLP system has been used to tackle 
a workforce management problem within British Telecom m- Also Telecom 
Italia is using a constraint-based system to schedule all its technical tasks (about 
100.000 tasks involving 20.000 technicians) over its territory da; the system 
which controls the whole workforce management has a scheduling module, called 
ARGO, which dispatches activities to technicians, and which makes extensive use 
of constraint propagation techniques. 

Network management. Another application domain for finite domain GLP is net- 
work management, where many different problems can be addressed and solved 
using GLP. 

The LOGARIM system was developed by GOSYTEG for France Telecom: 
starting from an architectural plan of a building, it proposes a cabling of the tel- 
ecommunication network of the building. The PLANETS system, developed by 
the University of Gatalonia in Barcelona for the Spanish electricity company, is a 
tool for electrical power network reconfiguration which allows to schedule main- 
tenance operations by isolating network segments without disrupting customer 
services. The company Icon in Italy produces a load-balancing application which 
is controlling network flow for the inter-banking system in Italy. The Esprit pro- 
ject GLOGWiSe (IN I03I6I) is using GHIP for the management and operational 
control of water systems. The planning of wireless digital networks for mobile 
communication has been tackled by the system POPULAR El, written in EG- 
LiPSe and then in GHR: the main advantages with respect to other approaches 
to this same problem (using traditional imperative programming) are a good 
balance among flexibility, efficiency, and rapid prototyping. 

Scheduling problems. Perhaps the most successful application domain for finite 
domain GLP are scheduling problems. Given a set of resources with given capaci- 
ties, a set of activities with given durations and resource requirements, and a set 
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of temporal constraints between activities, a “pure” scheduling problem consists 
of deciding when to execute each activity, so that both temporal constraints and 
resource constraints are satisfied. 

A typical example of a constraint-based scheduling application is ATLAS 
cza, which schedules the production of herbicides at the Monsanto plant in 
Antwerp. The PLANE system PI is used by Dassault Aviation to plan the 
production of the military Mirage 2000 jet and the Falcon business jet. The ob- 
jective is to minimize changes in the production rate, which has a high set-up 
cost, while finishing the aircraft just in time for delivery. The MOSES applica- 
tion was developed by COSYTEC for an animal feed producer in the UK: it 
schedules the production of compound food for different animal species, elimi- 
nating contamination risk and satisfying costumer demand with minimal cost. 
The FORWARDC system is a decision support system, based on CHIP, which is 
used in three oil refineries in Europe to tackle all the scheduling problems occur- 
ring in the process of crude oil arrival, processing, finished product blending and 
final delivery IZH). Recently, Xerox has adopted a constraint-based system for 
scheduling various tasks in reprographic machines (like pothocopiers, printers, 
fax machines, etc.); the role of the constraint-based scheduler is to determine 
the sequence of print making and to coordinate the time-sensitive activities of 
the various hardware modules that make up the machine configuration j/l)j . Re- 
cent results on the tractability of classes of constraint problems have shown that 
such scheduling problems are indeed tractable, and thus amenable for an efficient 
solution mni. 

Preemptive scheduling problems are those scheduling problems where activi- 
ties may be interrupted over time. Also for these problems CLP technology has 
shown its potential: the CLAIRE Scheduler is a constraint programming library 
which can successfully handle these problems, also in the presence of preferences 
mxm . A similar tool is the ILOG Scheduler m- 

By comparing the way scheduling problems are tackled by using imperative 
languages (C), generic CLP languages (CHIP), and specific constraint program- 
ming tools (CLP over sets), a recent study (on a specific scheduling problem: the 
cyclic hoist scheduling problem) has shown that the CLP approach is superior 
in many respects: development time, nodes visited in the search tree, number 
of generated feasible solutions, even efficiency |S|. According to this study, the 
main reason for the success of CLP on these problems is the use of constraint 
propagation, which helps to reduce both the development and the execution time 
when the solving algorithms are not precisely known. 

It has also been realized that, for some classes of scheduling problems, there 
is no one technique which is better than all the others, but rather a combination 
of several techniques is the best approach. Thus hybrid algorithms, employing 
both CLP and other techniques, have recently been developed. An example is 
the combination of CLP and Integer Programming, that has been used to tackle 
multiple-hoist scheduling problems nsg. 

Transport problems. A variety of transport problems have been tackled using 
constraints. These problems are often very complex due to their size, the number 
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and variety of constraints, and the presence of complex constraints on possible 
routes. Moreover, often these problems have a personnel allocation problem as 
a sub-aspect, usually with complex safety and union regulations. 

The COBRA system |172| generates diagrams representing workplans for 
train drivers of North Western Trains in the UK. For each week, around 25.000 
activities must be scheduled in nearly 3.000 diagrams, taking a complex route 
network into account. The DAYSY Esprit project (8402) and the SAS-Pilot pro- 
gram jO] considers the operational re-assignment of airline crews to flights. This 
same problem is tackled also by another system m which uses a combination of 
CLP and OR techniques. A recently developed system uses the ILOG constraint 
libraries to produce and optimize train operating plans for a freight railway com- 
pany, by creating transport movements for rolling stock between sources, hubs 
and sinks while satisfying transport requirements [nu- 

Also for transport problems (as for scheduling problems), in some cases the 
best method employs a combination of several techniques. For example, CLP and 
local search were both used to solve vehicle routing problems in PSBI, and in ina 
the same problems are tackled via a combination of CLP and OR techniques. 

Controlling electro-mechanical systems. CLP technology is also being exploited 
to build control software for electro-mechanical systems with a finite number 
of inputs, outputs, and internal states. Each component of a complex system is 
connected to a small part of the overall system, and its behavior can be captured 
quite simply, but when the system is considered as a whole the number of global 
states can become very large. Thus a smart technology that is able to handle 
such combinatorial explosion is needed. 

Control systems are needed for many applications, ranging from lifts, photo- 
copiers and car engines, to assembly lines and power stations. The applications 
currently being tackled with CLP technology are those at the smaller end, where 
it is still possible to prove that with a given control certain global properties of 
the system can be guaranteed. Typical properties that must be proved are safety 
properties (for example, that a lift should never start to move while the doors 
are still open), fairness properties (for example, that the lift must eventually 
answer all requests), and liveness properties (for example, that the lift eventu- 
ally will stop). A system tackling one of such applications and proving some of 
these properties is the system verification environment SVE m- Another one, 
mainly concerned with the verification of liveness properties in parallel systems, 
uses a combination of Petri nets and constraint programming within the 2LP 
programming language m- 

Constraint-based spreadsheets. The spreadsheet is one of the most prevalent 
decision support software tools in use today. However, usual spreadsheets have 
two limitations: they only compute in a fixed direction (from input cells to 
output cells), and the outputs can be defined only when the inputs are precisely 
defined. On the other hand, constraints allow variables to influence each other in 
all directions (like in A < Y), and work naturally with partial information (such 
as a variable with a non-singleton domain). The idea to apply CLP technology 
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to overcome these two limitations of the current spreadsheets has been taken up 
by several systems. 

The Short Term Planning (STP) application at Renault assigns product 
orders to factories so as to minimize transportation costs for delivering cars to 
costumers. This is a transportation problem with a lot of side-constraints, and 
usually it is unsolvable, so some of the constraints have to be relaxed. However, 
the absence of a fixed priority order or cost function, and the continuous changes 
in the context of the problem, requires that many decisions have to be taken by 
the end user. A constraint-based spreadsheet was developed to help the user in 
this task. During the planning process, the figures contained in the spreadsheet 
are not precise numbers, but intervals (min-max). Constraints are attached to 
different cells and are used to propagate the consequences of modifications impo- 
sed by the user, who can either enter a specific value for a cell (as usual), or just 
restrict the range of possible values by narrowing the interval. The system pro- 
pagates the consequences of such user choices by making them explicit: either an 
inconsistency is found, or tighter bounds are deduced for other variables. When 
the problem formulation is satisfactory, the user invokes a linear programming 
algorithm to produce an optimal solution. Since February 1995, the production 
of all Renault cars has been planned with the STP system. 

Another promising application of constraint-based spreadsheets is to financial 
planning m- the spreadsheet allows the financial planner to explore potential 
investments. Financial applications often involve non-linear constraints which 
are hard to handle with mathematical programming techniques. Reasoning on 
intervals makes this easier, since it is possible to compute the min and max of 
a non-linear function given the min and the max for each of its inputs. The 
problem of planning the budgets of the districts of Moscow, and to control that 
such plans are followed, has been recently tackled by using a constraint-based 
spreadsheet where the sub-definite constraint solving method is embedded within 
the ECLiPSe language m- 

Another example of a constraint-based spreadsheet is the Configuration 
Spreadsheet system [II 52) . which helps users to obtain a consistent and opti- 
mal configuration for problems like configuring a radio base station, or setting 
the parameters of mobile phone network transceivers. 

Interactive problem solving. For many applications, the end user must be able to 
cooperate with the software in developing solutions. CLP technology, especially 
constraint propagation, supports precisely the kind of feedback necessary for 
these applications. In fact, at each step the consequences of the particular choice 
are made explicit by the propagation engine. The user can then either reject the 
choice, or use the propagated information to make the next choice, or allow the 
system to continue the search automatically. 

For example, constraint programming systems with this kind of behavior 
have been developed to address the timetabling problems of Banque Bruxelles 
Lambert and of the Medical Faculty of the Humbolt University m- Ano- 
ther system m assigns cashiers for El Corte Ingles in Spain, and another one 
m allocates gates at Changi airport. This last system supports several different 
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Gantt chart displays which allow to manipulate graphically the resource assig- 
nments. Yet another system allows for the interactive construction of a solution 
for a nurse scheduling problem, and it has been tested at a clinic in Munich 

The need for interactivity may also arise from the fact that in some applicati- 
ons it may not be feasible to acquire all problem features at the beginning. This 
is what may happen for example in 3D object recognition problems, where vi- 
sual feature acquisition is a very time-consuming task. For this reason, a recently 
developed system, based on ECLiPSe, allows to have only some features present 
when starting the solution process, and to interactively acquire the others on 
demand only when needed m 

Another class of problems that may require interactivity are those which are 
ill-defined, and thus require further refinement. Examples of such problems are 
the speculative constraint problems, which arise when one wants to anticipate 
future changes and decide what to do accordingly. A recent study of these pro- 
blems, applied to the specific problem of risk management in energy trading, 
has shown the potential of constraint technology to handle also this kind of 
interactivity Ea 

Graphical interfaces. Another large (and one of the oldest) application area 
for CLP technology is graphical interfaces. The role of CLP here is to keep all 
the graphical objects in the correct relation to each other, after some update 
to the graphical window - typically via a mouse. Thus the objective is not 
to find an optimal solution, but a natural one, and relatively quickly. Also, 
constraint propagation in graphical interface applications has to be fast and 
has to propagate changes, not just refinements; moreover, inconsistencies are 
not possible, and must therefore be handled by making further changes. For 
example, in an electronic room planning application, it might be possible to drag 
a graphical chair across a graphical room, but the constraints should prevent it 
from occupying a position which overlaps with the position of any other piece 
of furniture in the room El- 

In reality, constraints and graphical interfaces may interact in two ways: 
on one side, constraints may be used to provide added features to graphical 
interfaces. On the other side, graphical interfaces (either based on constraints or 
on traditional techniques) may be useful in many CLP applications to help the 
user in the modeling phase. In the following we give examples of both kinds of 
systems. 

A commercial constraint library for constructing interactive graphical user 
interfaces is presented in |2S|- The company Object Technology International 
has used this library to build a graphical editor for a large database. A recently 
developed object-oriented constraint solving toolkit, called QOCA, provides a 
simple and flexible interface for interactive graphical applications [129j . Such 
a system has been used in graphic editors, for the error correction in visual 
language parsing, for graph layout, and for interactive document layout on the 
Internet. Another constraint solving algorithms, especially designed for interac- 
tive graphical applications, is Ultraviolet m- Constraints have also been used 
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to add useful features and efficiency to graph drawing algorithms ina, and to 
generic visualization and animation tools CZH]. 

A graphical interface using constraint-based techniques has been developed to 
solve the assembly problem (that is, the spatial joining of separate rigid bodies) 
within professional CAD/CAM systems |167| . The language EaCL IMI has been 
designed to help users to specify constraint satisfaction problems; it relies on the 
ZDC user interface, which allows to specify variables, domains, and constraints, 
and provides also on-line tutorials and examples. 

Overconstrained problems. Many real problems are overconstrained: the user 
puts so many constraints that it is impossible to satisfy all of them. In these 
cases, we first have to find out that there are no solutions (and it may take a 
long time to do this), and then we have to decide which constraints to relax so 
as to make the problem solvable. To solve this second problem, one approach 
is to ask the end user to make some decisions, as in the interactive problem 
solving applications described above. Otherwise, we can associate a cost to each 
constraint, or form a hierarchy of constraints (where higher constraints are more 
important) [2^, or, more generally, resort to soft constraints |68l6()ll58ll6dl2l| . 

Typical over-constrained problems are timetabling problems, where const- 
raints come from many sources (like the availability of rooms and all the profes- 
sors’ preferences). A recent system uses both hard and soft constraints to model 
and solve time-tabling problems at the University of Siegen, Germany mu, and 
another system employs two phases of constraint satisfaction (the first one to 
assign faculty to courses, and the second one to assign time slots to courses) to 
solve the timetabling problems of the Computer Science program of the Florida 
Institute of Technology | 22 |. Another system, which tackles over-constrained pro- 
blems by using a hierarchical constraint system, is currently tested at the DRK 
hospital Neuwied to solve the nurse scheduling problem 

Other application domains. A hard problem that has been recently tackled using 
the CLP technology is the protein structure prediction problem, which is one of 
the most important problems in computational biology ^ . This problem consists 
of finding the conformation of a protein with minimal energy. It seems that the 
use of constraints helps to reduce the amount of search involved in this NP- 
complete problem. 

Constraints have also been used by Sony for several applications related to 
music |ES|. One of the problems tackled by Sony is the automatic harmoniza- 
tion problem: given a melody, the task is to compute a four-voice harmoniza- 
tion of the melody, which satisfies the rules of harmony and counterpoint. The 
rules of harmony are very natural to describe as constraints, since they typi- 
cally state incompatibilities. The Sony application solves this problem by using 
structured variables which represents chords, and by using arc-consistency-based 
algorithms. Another Sony application related to music is the Active Listening 
project, which allows a music listener to set some constraints, which may state 
for example that some instruments are linked together. A typical constraint of 
this kind may state that the volume of the drum and the bass must be equally 
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strong, or that there must be a balance between two sound sources. During the 
play of the music, the listener may change the volume of some instruments, but 
the system makes sure that all the constraints must be satisfied. A recent Sony 
application of constraints to music is the RecitalComposer project, which pro- 
duces sequences of music titles, taken from a large-scale catalogue, according to 
certain user preferences, some global properties on the coherence of sequences, 
and some constraints on the access to the catalogue. 

4 Research vs. Applications in the CLP Commnnity 

By looking at the proceedings of the CP conferences |ld 6 l 66 llV 6 ll 28 lia^ since 
their birth in 1995, we tried to understand whether the current CLP community 
is working more on using the current technology to build useful and efficient 
applications or on extending/adapting/modifying the technology from the theo- 
retical point of view to be able to, later, tackle even more complex applications 
in a better way. The curves in Figure Q show the percentage of application, con- 
straint programming, and constraint solving papers in the proceedings of all the 
CP conferences held so far. We did not use the proceedings of the PACLP con- 
ferences for this graphic because they are too biased toward application papers, 
which make almost 100% of the accepted papers every year. 




CP95 CP96 CP97 CP98 CP99 

Proceedings of the CP conferences 



Fig. 1. Theory vs. applications in the CLP community. 



Constraint solving is more than half of the work. The main thing we noticed in 
these results is the large percentage of papers on constraint solving (always more 
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than 50% in the last three years) over all the other kinds of papers. This is in 
some sense reasonable: constraint solving is needed both for solving constraint 
problems and also for programming with constraints. Thus the results of such 
papers are useful for the vast majority of the CLP community. 

Application papers. Another point is that the percentage of application papers is 
not so high: at most 24%. Although this may seem strange, it is understandable 
by considering that there is an annual conference (PACLP) entirely devoted to 
this subject. However, at least 10% of the papers are always on applications. 
This means that the CLP technology has so many application domains that 
original and interesting application reports can easily exceed the space of an 
annual conference devoted to them. 

Constraint programming papers. The third line represents the percentage of con- 
straint programming papers, where by constraint programming we mean both 
CLP and also other kinds of programming paradigms using constraints (like 
imperative, object-oriented, ...). In the three years before 1998 such a line 
of research has contributed for at most 17% of the papers. This may suggest 
that in those years people were more interested in supplying existing constraint 
programming languages with new constraint solving techniques (thus the high 
number of constraint solving papers) rather than developing new languages for 
constraint programming. The 1998 trend in producing more constraint program- 
ming papers seems to be due to the need of augmenting existing CP languages 
with useful tools that make CP programming easier and more user-friendly. 



5 A Questionnaire about CLP Applications 

The information provided by the PACL conference proceedings and by the ap- 
plication papers at the CP conferences could provide, in our view, a reasonable 
snapshot of the current state-of-the-art in CLP-related applications. In fact, 
these are the main sources of information that we used to write our application 
survey. However, they could give us only a partial view of some important issues 
related to CLP applications domains and technologies. In particular, they could 
only partially give us the motivations underlying a certain piece of work or the 
choice of a certain technology, nor they could tell us about all the application 
needs that could not be addressed by the current technology. For this reason, 
and in order to build a more complete picture, we have prepared a questionnaire 
on CLP applications, where the questions were mainly related to how much, and 
which kind of, constraint technology was used, what were the major advanta- 
ges and drawbacks, and what were the needs not yet addressed by the available 
tools. 

The questionnaire was distributed among the participants of the PACL 1999 
conference, and also among the members of the Compulog Net m mailing list. 
A total of 35 fully-filled questionnaires were returned, and here is a list of the 
main things we observed in the answers. 
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Which application tools? This question was asking which tool is used to tackle 
applications. From the answers, it turned out that there is no one winning tool, 
but instead several different languages are currently used to develop CLP ap- 
plications: Hog Solver, Chip, Sicstus Prolog, CLP(R), ECLiPSe, Ciao, Oz, IF- 
Prolog, clp(fd), and also proprietary systems. Among all these tools/languages, 
Sisctus Prolog and ECLiPSe are by far the most popular (13 and 11 preferences 
respectively), followed by ILOG Solver (6 preferences), CHIP (5) and IF-Prolog 
(4). The fact that some of these languages are almost free for the academia 
(like Sicstus Prolog and ECLiPSe) may of course influence the preferences of the 
users. 

Which application problems? The second question was about the applications 
that are tackled via CLP-related technology. Here, as predictable, the list is 
very long, but scheduling is by far the most studied: 22 preferences. Then we 
have resource allocation (12), graphical layout (6), and vehicle routing (3). All 
other applications had just one or two preferences; among them, we may notice 
the presence of some non-standard domains, like printed-circuit board design, 
3D object recognition, consistency checks of rule sets, properties of logic pro- 
grams, music, DB integration, protein topology, speculative projects, and web 
applications. 

Advantages of CLP? The next question was about the advantages of current 
CLP technology. Expressivity was the most chosen (27 preferences), followed 
by ffexibility (25 preferences) and fast prototyping (24 preferences). The other 
answers (easy to use and easy to learn) were not neglected (8 and 5 preferences 
respectively) but evidently have less impact on the CLP community. 

Drawbacks of CLP? We also asked to list the drawbacks of current CLP tech- 
nology, and we provided three answers: not easy to learn (18 preferences), not 
efficient enough (15 preferences), and difficult to adapt to specific problems (7 
preferences). From such answers, we can see that even for people within the 
CLP/LP/Computational Logic community, current CLP tools are not easy to 
learn, which is in some sense surprising. However, it is true that to learn the 
basics of a CLP tool is very easy, but it is usually very hard to learn how to 
exploit its full power. 

Needs not yet addressed by CLP? The question about the drawbacks leads to 
the next, and in our view, most interesting, question about the needs that arise 
from the application domains that current CLP technology cannot fulfill. Here 
we had a lot of different answers, but the most chosen one was the need for tools 
dealing with over-constrained problems (14 preferences). It is in fact notorious 
that CLP experts dealing with user-specified constraint problems often report 
of over-constrained situations. The next most chosen answer was the need for 
tools dealing with user preferences (12 preferences). This need is of course re- 
lated to over-constrained systems, but it also arises from real problems where 
preferences are an intrinsic feature (like timetabling) . Then we have the need for 
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modeling tools (10 preferences). In fact, it is only recently that this aspect has 
been considered, and modeling tools/languages have been developed (see Sec- 
tion 0 ). Many other needs were listed, like for debugging tools, for tools dealing 
with dynamic constraint problems, for the integration of different solvers, for 
explanation tools, and for tools that help to study the complexity of a problem 
and possibly discover its tractability. 

Summarizing, what we learned from these questionnaires is that current CLP 
technology provides a lot of useful tools/languages, which offer high expressivity 
and flexibility, and allow a fast prototyping phase. Many applications are cur- 
rently successfully tackled by such tools. However, if we want to make CLP a 
successful technology for most real-life problems we still need to improve its 
modeling, solving and explanation capabilities, especially in the context of over- 
constrained problems and problems with preferences. 

6 Future Opportunities for CLP Applications 

As shown in Section 0 and also by the answers to the questionnaire, many and 
diverse application problems are currently being tackled with great success by 
the CLP technology. However, there are still some problem features that have 
not been exploited by using constraints, and also some new application domains 
which only very recently CLP started to explore. 

6.1 In Current Domains 

There are so many application domains that are currently addressed by using 
CLP, that it is difficult to say what has to be done better or more in such 
domains. However, we would like to point out two aspects of current CLP tech- 
nology that are in our view still underestimated in such domains, and not as 
used as they should be. However, we understand that such aspects also involve 
many research issues, still to be studied, and thus we will discuss them also later 
in the section devoted to the research challenges for CLP (Section 0. 

More Use of the Modeling Languages/Tools. As noted above, one of the main 
needs for many applications is to have some help in the modeling phase, when 
the user description of the problem has to be transformed into a specification 
that the CLP language at hand can handle and solve. Some modeling tools 
and languages have recently been developed (see Section 0, and they should 
definitely be used to achieve a good model of the real life problem. This is 
especially true for problems with preferences or soft constraints, since otherwise 
these intrinsic features could be lost. 

More use of soft constraint technology. Soft constraints have recently been de- 
veloped to generalize classical hard constraints and make them more general. 
Some applications have already been developed to solve problems usually tackled 
by classical constraints, like time-tabling and workforce management, by using 
some tool to model and handle soft constraints. In this way, user preferences and 
other soft features could be considered in the problem formulation. However, it 
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seems that most of the problems currently tackled by the CLP technology are 
still expressed and solved by using classical hard constraints. This may make 
the modeling process easier at first, but it may also generate apparent over- 
constrained problems or also an unnecessary level of user’s involvement in the 
solving process. We believe that by using the current technology on soft con- 
straints (although it is far from being completely satisfactory, see later), most 
of these problems could be represented more faithfully and then solved more 
automatically. 



6.2 In New Domains 

Although constraints have been around for more than 30 years, it is only recently 
that they have reached the state of a full-fledged research area, as illustrated by 
the existence of international conferences and journals devoted to this domain. 
Moreover, the relatively recent developments of CLP languages and systems has 
allowed for a wide applicability of this technology, as shown by all the applica- 
tions listed in Section |3 

However, it is also a widespread feeling that CLP techniques are vastly un- 
derexploited outside the CLP community. The reason for this is that constraints 
are often misunderstood outside this community. For historical reasons, CLP is 
seen as an extension of logic programming, and the relative decline of application 
areas for this branch of computer science, combined with the end of the Japa- 
nese 5th generation project, do not contribute to promoting the field. Culturally, 
constraints are often considered a new mathematical approach for classical OR 
problems, thereby inspiring suspicion. Technically, constraints are critiqued as 
being a purely engineering branch of computer science, which therefore should 
only be considered as a mere reformulation of standard optimization techniques. 
Of course there is much more to constraints, but it is true that CLP lies in 
an undefined zone between theoretical research and engineering, which makes it 
difficult to clearly define what constraints are. For this reason, it is important 
that constraints are starting to be used for new application domains, so that 
people outside the CLP community can see their real advantages. 

Multimedia. We believe that multimedia is one of such domains, for several 
reasons inn!. First, the availability of large catalogues of multimedia informa- 
tion to users via networks creates a huge demand for high-level user services. 
Second, the possibility, with digital representation of audio-visual signals, to in- 
corporate the so-called ’’content information” together with the data (see the 
Mpeg-4 standard for audio, or the upcoming Mpeg-7 standard for audio- video) , 
makes it possible to use symbolic techniques such as constraints to specify and 
solve problems related to audio- video manipulation and access. These issues may 
create new instances of classical problem domains, like scheduling for digital au- 
dio broadcasting, or also completely new classes of problems, like those involved 
in providing a music listener with a control system which has both interactivity 
and flexibility. 
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Virtual reality. Another new domain where constraints could be useful is the area 
of virtual reality yt8| . In this domain, many interactions (or forbidden interac- 
tions) between objects can be seen as constraints, and implemented efficiently as 
such. This generalizes in an obvious way 2D geometrical constraints. The VRML 
language m is currently quite successful for describing 3D virtual worlds. In- 
teraction between objects is performed in VRML by propagating events through 
routes, linking the output event of an object to the input event of another ob- 
ject, or by using the predefined “interpolators” . However, nothing prevents to use 
some Java subprogram instead of these interpolators. Such Java programs can 
indeed represent constraints, in the form of generic propagation rules, and the- 
refore constraints can be used to describe the relations between virtual objects, 
bringing much richer relations and interactions in the virtual world. 



Bioinformatics. The use of computer science technology to harness the comple- 
xity of biological structures seems to become a very crucial issue. In this respect, 
it is predictable that constraint-related techniques could help in the exploration 
and search of the vast amount of data that usually have to be handled in these 
kind of applications. Some work has already been done in using constraints for 
pattern-based search and analysis of bioinformatics databases (genomic, proteo- 
mic and metabolic), and interactive visualisation and exploration of biological 
data |78I27I7| . but we still have to discover the full power of constraints in this 
fascinating application area. 



Network-wide programming. A third new domain where CLP could have a sig- 
nificant role is network-wide programming. This type of programming is bound 
to be of growing importance due to the popularity of Internet and the WWW 
protocols. CLP systems appear to have a number of features which could place 
them well to make an impact in this area, like dynamic memory management 
and compilation to architecture independent byte-code. Moreover, the notion of 
constraint entailment which comes from the CC framework offers a rich notion 
of inter-process communication and synchronization. Also, it seems natural that 
the more sophisticated network applications, such as intelligent information re- 
trieval or distributed decision making, will require complex symbolic and numeric 
capabilities, at which CLP has already been shown particularly successful. 



7 Research Challenges 



According to the results of our questionnaire, there are many real needs that 
currently the CLP technology cannot address fully. For some of them there is 
already some ongoing effort, and thus we may predict the birth of practical tools 
in the next few years. Nevertheless, for most of the research challenges we list 
below, a complete answer should involve so many aspects that we may predict 
a longer term research effort, and a satisfactory answer, both for theoreticians 
and application people, only in several years. 
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Again, we need to remark that the list below cannot be complete, mainly 
because of our lack of an adequate level of understanding of the numerous re- 
search areas within CLP. However, some of the gaps of this list can be filled by 
looking at a special issue of the CONSTRAINTS journal devoted to “Strategic 
Directions in Constraint Programming” m- 

Modeling. It seems that the most urgent of all needs, but also the longest to 
be achieved in our view, is the possibility to have user-friendly tools that allow 
to model constraint problems in a faithful way. Such tools should be very high- 
level, because the user should concentrate on the main issues and not on the 
details, and should also provide a reasonable level of interactivity, because a black 
box cannot be convincing enough for the user. This raises issues of knowledge 
acquisition, effective representation, and possibly also problem reformulation 
and abstraction. Current CLP research should move into this direction, maybe 
also by using foreign technologies (negotiation and learning are already being 
used) to provide enough help during the modeling phase. These studies are 
most important as we think that different models may lead to very different 
performances. This research challenge is obviously a long-term goal, since it 
may take a long time to develop new modeling techniques and to combine them 
together to achieve an integrated modeling environment. 

Soft constraints. Preferences (or similar concepts) arise in many real problems. 
Although there are already a number of constraint-based approaches to forma- 
lize such features, we still need to work to develop efficient and general methods 
to solve soft constraints and to program with them. Also the modeling issue 
described above assumes in this context an additional complexity. In fact, mo- 
deling a soft constraint problem is in general more difficult for the user, since 
he/she must be able to clearly state all the soft features of the real problem at 
hand (preferences, uncertainties, fuzziness, etc.). Also, solving a soft constraint 
problem means not just finding one solution, as in the classical hard constraint 
case, but finding a good solution, since the soft features introduce optimization 
criteria (often more than one). 

Interactive/explanation tools. This need for interactivity applies not only to 
the modeling phase, but also to the solving phase, especially when the initial 
problem is over-constrained. In fact, the user needs to know why no solution 
exists, and has to be involved in the process of modifying the constraint set 
in order to find a solution. Therefore, good interactive solving tools, as well as 
explanation tools, should be provided. Some interactive systems already exist 
(like most of the constraint-based spreadsheets listed above), but we are still far 
from having a general environment which cooperates with the user to solve a 
constraint problem. 

Integration of CLP with other techniques. Another important topic for future 
research is the integration of constraint programming with other programming 
or solving techniques, like integer programming. The integration can take various 
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forms. For example, the introduction of constraints within a branch-and-bound 
scheme, or the redundant modeling of a problem by using both methods and 
making the two models communicate. 

The integration need is felt also at a higher level: the satisfaction approach 
(to find a solution of a constraint problem) and the perturbation approach (given 
a solution, find another one) need to be re-united. Most of the work in the CLP 
area has so far focussed on the satisfaction approach, which assumes a static 
view of constraint problems, but in a lot of real problems we need to find a 
new solution after a perturbation of an old one. Some work has been done to 
integrate these two viewpoints, but we are still far from having a system where 
both approaches coexist. 

Debugging /visualization tools. One of the most common problems stated by 
users of CLP systems is their sometimes unpredictable behavior. Even small 
changes in a program or in the data can lead to a dramatic change in the per- 
formance. To help in this respect, new and more advanced debugging and visua- 
lization tools should be provided, in order to foster the development of programs 
which are more stable over a variety of data. This is maybe the most short-term 
of the research challenges listed here, since there is currently an Esprit project 
devoted to this research area. Thus we have already seen some interesting results 
in this direction, and we may expect to see other results soon. 

Search control tools. Related to the above point, is the need of search control 
tools, that would allow a better understanding of what happens during the search 
for a solution. For many problems, the choice of a search routine can be crucial to 
the performance, but currently it is generally developed on an ad hoc basis. The 
possibility of studying the effect of different search methods, either in alternative 
to the usual depth-first chronological backtracking, or in combination with it, 
could provide dramatic improvements in solution quality and solving efficiency 
for many hard problems. 

Global constraints. It is predictable that requirements for particular applications 
will lead to the creation of new global constraints. This will require new rese- 
arch efforts to develop efficient constraint propagation techniques for such new 
constraints. 

Implementation of CLP systems. The performance of current CLP systems often 
compares favorably to other constraint solving and programming tools. However, 
their performance is still lower in many cases than that of traditional imperative 
languages. To fill this gap, advanced compilation and global analysis tools should 
be developed, as well as automatic parallelization techniques 

Network-wide programming. As noted in the previous section, CLP tools could 
be of some help in future systems for network-wide programming. In fact, CLP 
systems seem to have some features which are appropriate for using them in 
this area, and also some notions which are new to the area (like constraint 
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entailment), which could make current network applications more sophisticated. 
However, it is easy to imagine that this is not just an application issue, since 
also research issues are touched when trying to use current CLP technology in 
this area. A few examples of such issues are the introduction of the notions of 
mobility and distribution in CLP, as well as the communication among solvers on 
different sites, both for distributed consistency checking and also for knowledge 
extraction from different sources. 



8 Conclusions 

We hope to have shown in this paper that the CP technology and research is by 
now mature enough to tackle a number of hard problems. Most application areas 
by now use CP-related results and algorithms to either solve their problems more 
efficiently, or in a more declarative and flexible way. 

However, we have also pointed out several current needs of the users, and 
discussed the work which still needs to be done to address them. This work 
includes several areas and lines of research and development, and in our view it 
must concern mainly the following issues: the possibility of being helped during 
the modeling phase, a certain level of interactivity during the solving process, and 
the use of preferences in both over-constrained problems and also in intrinsically 
soft problems. We are highly confident that the CP community will be able to 
carry out this work and achieve several useful results that will allow both to 
satisfy the current needs, thus making the CP technology more interesting and 
practically usable for a larger community, and also to investigate new ways of 
using the CP machinery within other research communities, in a way that that 
will improve them as well. 
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Abstract. This paper is a brief introduction to OPLScript, a script langu- 
age for composing and controlling optimization models. OPLScript makes it 
possible to state concisely many applications that require solving several 
instances of the same model (e.g., to perform some sensivity analysis), 
a sequence of models, or a combination of both as in column-generation 
applications. OPLScript also enables modellers to exercise some control over 
a model and/or to use traditional scripting facilities. The basic abstrac- 
tions of OPLScript are the concepts of models and abstract models that make 
it possible to develop, maintain, test, and reuse models independently of 
the scripts using them and to develop scripts that apply to a variety of 
models. 



1 Introduction 

The last decades have witnessed the development of many modeling langua- 
ges for mathematical programming (e.g., m)- These languages significantly 
decrease the development time of optimization applications by providing high- 
level algebraic and sets notations and data modeling facilities. Recent modeling 
languages such as OPL 0 further enhance these functionalities by supporting con- 
straint programming notations and technologies and by letting modellers specify 
their search procedures for combinatorial optimization problems. 

Many practical applications however involve more than just solving a model, 
even when their combinatorial aspect is considered in isolation. Typically, these 
applications require solving several instances of a model (e.g., to perform some 
sensitivity analysis), a sequence of models where the solutions of one model are 
the inputs of the next model, or a combination of both as in column-generation 
applications. In addition, some of these applications may need to exercise some 
control over the search procedure to improve performance, to obtain a reason- 
able solutions quickly, or, more generally, to tailor a general model to a given 
application. 

This paper is a brief introduction to OPLScript, a script language for composing 
and controlling optimization models. By combining high-level data modeling 
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facilities of modeling languages with novel abstractions for composing and con- 
trolling models (e.g., abstract models, bases, ...), OPLScript simplifies significantly 
the implementation of these applications. In addition, by encapsulating the ge- 
neric aspects of models, OPLScript makes it possible to use traditional scripting 
functionalities over models (e.g. iterating over a collection of models or imple- 
menting generic search procedures). Finally, by abstracting irrelevant aspects of 
models, OPLScript makes it easy to combine models using different implementation 
technologies (e.g., mathematical and constraint programming). 

To stress the contributions of OPLScript, it is interesting to contrast it with se- 
veral tools, including AMPL, constraint programming languages, and traditional 
script languages. 

— The procedural extensions of AMPL were motivated by similar considerati- 
ons but OPLScript provides both novel functionalities and higher-level abstrac- 
tions. These features endow OPLScript with traditional scripting functionalities 
and the ability to define generic search strategies, both of which are outside 
the scope of AMPL. In addition, the resulting separation of concerns and 
encapsulation make it possible to develop, test, and maintain models inde- 
pendently from the scripts using them. Finally, OPLScript supports the compo- 
sition of models implemented by fundamentally different technologies (e.g., 
mathematical and constraint programming). 

— The applications described in this paper can already be implemented in con- 
straint programming languages such as CHIP P|, CLAIRE jS|, ECLIPSE 
15, the Hog optimization suite jOI, and OZ 0. This is of course not surpri- 
sing since these languages are Turing-complete. The main contribution of 
OPLScript is to simplify further the development of these applications by com- 
bining traditional data modeling facilities of modeling languages with novel 
abstractions for composing and controlling models. These abstractions re- 
lieve modellers from tedious design and implementation effort and let them 
focus on high-level modeling issues. 

— OPLScript also goes far beyond traditional scripting languages by providing very- 
high level data modeling and control features and by providing abstractions 
that are specific for optimization applications. In this context, OPLScript is best 
viewed as a domain-specific script language for optimization. 

The rest of this paper highlights some of the functionalities of OPLScript by presen- 
ting some small, but representative, applications. Section 2 is a short presenta- 
tion of the main concepts by means of simple examples. It introduces models and 
to use them to find solutions and/or optimal solutions and open arrays to store 
an unknown number of solutions or configurations in column-generation appli- 
cations. The next three sections describe a script to solve several instances of a 
production model, a script to solve the so-called Vellino problem that sequences 
two models using different technologies, and a script for a column-generation 
application. These sections introduce functionalities such as the ability to im- 
port data between scripts and models and linear programming bases to achieve 
more performance in column-generation applications. Section 6 describes more 
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traditional script fonctionalities: it introduces the concept of abstract models 
and the ability to control models in OPLScript. Section 7 concludes the paper. 

2 Getting Started 

Since OPLScript is a script language for composing and controlling models for op- 
timization problems, it is thus not surprising that models are a fundamental 
concept of the language. Consider the script 

Model mC'nqueens .mod" , "nqueens . dat ") ; 
if m. solve 0 then 

foralKi in l..m.n) { 

cout « "queens [" « i « "] = 
cout « m. queens [i] << endl; 

} 

that displays a solution to a queens problem. It uses the OPL model file nqueens . 
mod (see Figure ^ and the data file nqueens . dat to declare a model m. The 
instruction m. solve () solves the model, i.e., in this case, it finds a solution 
to the model. The rest of the statement uses the model objects to display the 
solution. Since models in OPLScript have their own scope, the various data declared 
in nqueens. mod are accessed through m in the same way as fields of records. In 
particular, m. queens [3] denotes the value of queens [3] in nqueens. mod. 



int n = . . . ; 

range Domain l..n; 

var Domain queens [Domain] ; 

solve 

forall (ordered i,j in Domain) { 
queens [i] <> queens [j]; 
queens [i] + i <> queens [j] + j; 
queens [i] - i <> queens [j] - j 



Fig. 1. The n-Queens Model (nqueens . mod) . 



Consider now the script 

Model mC'nqueens .mod" , "nqueens . dat") ; 
int n : = 0 ; 

while m.nextSolutionO do 
n : = n + 1 ; 

cout « "Number of Solutions: " << n << endl; 
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that illustrates how to compute and display the number of solutions to the queens 
problem. It uses the instruction m.nextSolutionO that computes successive 
solutions to the model m. More precisely, the first call to nextSolution computes 
the first solution, the second call the second solution, and so on until all solutions 
have been found. For optimization problems, instruction nextSolution can be 
used to obtain successive solutions, each of which improving the best value of 
the objective function found so far. More precisely, the first call computes the 
first solution, the second call computes another solution with a better objective 
value and so on until no solution improving the best solution obtained so far is 
found. For instance, the script 

Model m( "bridge .mod" , "bridge . dat") ; 
while m.nextSolutionO do 

cout « "Objective value: " << m. objectiveValue () « endl; 

displays the objective value of the successive solutions found to the bridge pro- 
blem Q. To obtain the optimal solution, it is sufficient to enhance the script by 
using the restore method on the model: 

Model m( "bridge .mod" , "bridge . dat") ; 
while m.nextSolutionO do 

cout « "Objective value: " << m. objectiveValue () « endl; 
m.restoreO ; 

cout « "Objective value: " « m. objectiveValueO << endl; 

This method restores the last solution found by nextSolution, thus retrie- 
ving the last solution found so far. For linear programs, of course, method 
nextSolution returns the optimal solution directly. In optimization problems, 
the optimal solution of a model can be obtained directly by using method 
solve 0 as in 

Model mC'bridge .mod" , "bridge .dat") ; 
if m. solve () then 

cout « "Objective value: " << m. objectiveValue () « endl; 

Assume now that we are interested in storing all the solutions of the queens 
problem. A possible, but inefficient, solution consists of counting the solutions, 
declaring an array of the appropriate size, and then filling the array by solving 
the problem again. A more elegant and efficient solution consists of using an 
open array. An open array is an array that grows or shrinks dynamically at 
runtime. The script depicted in Figure El illustrates how open arrays help solve 
the problem. The instruction 

Open int solution [1 .. 0, 1 . .m.n] ; 

defines a 2-dimensional open array of integers, i.e., an open array of open arrays 
of integers. The first dimension is an empty range in the declaration and hence 
the open array is empty as well. When a solution is found, the method call 
solution. addhO increases the upper bound of the open array solution by 
one (addh stands for “add high”). The first time this instruction is executed in 
the above script, the array solution becomes an array of one element whose 
only index is 1 and whose value is an array that has not yet been initialized. 
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Model mC'queens .mod" , "queens .dat") ; 

int nb : = 0 ; 

Open int solution [1 .. 0, 1 • -ni-n] ; 

while m.nextSolutionO do { 
n : = n + 1 ; 
solution. addhO ; 
foralKi in l..m.n) 

solution [n, i] := m.queens[i]; 

} 

foralKs in l..n) { 
foralKi in l..m.n) 

cout << "queens [" << i << "] = " « solution [s , i] « endl; 
cout « endl; 

} 



Fig. 2. A Script to Store All Solutions (storequeens . osc) . 



The instructions 

foralKi in l..m.n) 

solution [n, i] := m.queens[i]; 

initializes this dynamically created array in the traditional way. The remaining 
instructions display all solutions. 

It is important to stress that a model is best viewed as an object and its 
data, variables, and constraints can be tought of as instance variables. After a 
model has been solved, its results can be accessed as in OPL. For instance, it is 
possible to obtain their values, the slack of the constraints, the dual variables in 
the case of linear programs, and any other results provided by OPL. 



3 Solving Several Instances of a Model 

Practical applications often require to solve several instances of a model in order 
to perform various forms of sensibility analyses or to execute “what-if” scenarios 
on a model. This section illustrates how such an application can be expressed in 
OPLScript using a simple production planning model. The model is not shown for 
brevity, since it is not necessary to understand its detail to follow the discussion. 
It suffices to know that products can be produced either inside or outside the 
factory. The inside production is cheaper but is limited by the resources (capacity 
constraints). Consider the script 

Model produce ("mulprod. mod") editMode; 
import enum Resources produce. Resources; 
int+ capFlour := produce . capacity [flour] ; 
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foralKi in 1..4) { 

produce . capacity [flour] := capFlour; 
produce . sol ve () ; 

cout « "Objective Function: " « produce . objectiveValueO << endl; 
produce . reset ( ) ; 
capFlour := capFlour + 1; 

} 

The instruction 

Model produce ("mulprod. mod") editMode; 

declares the model in edit mode, which makes it possible to edit the instance 
data. The next instruction imports the enumerated type Resources from the 
model to the script in order to simplify the rest of the statement (i.e., it enables 
the script to use flour instead of produce . flour. The loop of the script solves 
4 instances of the model that differ by the capacity of resource flour which is 
incremented by one at each iteration. 

This model is a linear program and hence it may be appropriate to use the 
optimal basis of an instance as a starting point for solving another instance. Such 
a basis represents a vertex of the polyhedron defined by the linear program and 
starting from a good vertex may speed up the linear program significantly. OPLScript 
supports this functionality by providing the concept of linear programming basis. 
The loop of the script depicted previously can be replaced by the instructions 

foralKi in 1..4) { 

produce . capacity [flour] := capFlour; 
produce . solve ( ) ; 

cout « "Objective Function: " « produce . objectiveValueO << endl; 

Basis b (produce) ; 

produce . reset ( ) ; 

produce . setBasis (b) ; 

capFlour := capFlour + 1; 

} 

to take advantage of this facility. The instruction Basis b (produce) declares a 
basis and initializes it with the optimal basis of model produce. The instruction 
produce . setBasis (b) specifies that basis b must be used as a starting basis 
when solving model produce. This use of bases may significantly decrease the 
number of iterations for linear programs. As shown later in this paper, OPLScript also 
support partial bases, i.e., bases that only specify the basis status of some of the 
variables and constraints, which is particularly useful when solving a sequence of 
problems where the number of variables and/or constraints increase dynamically. 

It is important to step back at this point and stress some important con- 
tributions of OPLScript here. First, note that (partial) linear programming bases 
are first-class objects that represent fundamental abstractions for mathematical 
programming. By providing such abstractions, OPLScript makes it possible to sup- 
port efficiently fundamental techniques from mathematical programming. Se- 
cond, note that such extension do not change the nature of the models. A model 
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can still be viewed as an object that simply has an additional instance variable 
to store a linear programming basis. The basis, if it exists, is used as a starting 
point to solve the model. 

Finally, it is interesting to show a final version of the loop where the dual 
values are used to control the number of iterations. Consider the instructions 

repeat { 

produce . capacity [flour] := capFlour; 
produce . solve ( ) ; 

cout « "Objective Function: " « produce . objectiveValueO << endl; 
float sumDual := sum(t in produce. Periods) produce . cap [flour ,t] . dual ; 
if sumDual = 0 then 
break; 

Basis b (produce) ; 
produce . reset () ; 
produce . setBasis (b) ; 
capFlour := capFlour + 1; 

} until 0; 

The instruction 

float sumDual := sum(t in produce . Periods) produce . cap [flour ,t] .dual; 

computes the summation of the dual values associated with the capacity con- 
straints. In the model, cap is a 2-dimensional array of capacity constraints inde- 
xed by the resources and by the time periods. When this summation is zero, the 
loop terminates since it means that the objective function cannot be improved. 



4 Sequences of Models 

The previous section has illustrated how to solve several instances of the same 
problem. This section shows how to solve an application consisting of a sequence 
of two models: a constraint programming model and an integer program. The 
application is a configuration problem, known as Vellino’s problem, that is a 
small but good representive of many similar applications. For instance, complex 
sport scheduling applications can be solved in a similar fashion. 

Given a supply of components and bins of various types, Vellino’s problem 
consists of assigning the components to the bins so that the bin constraints are 
satisfied and the smallest possible number of bins is used. There are five types 
of components, i.e., glass, plastic, steel, wood, and copper, and three types of 
bins, i.e., red, blue, green. The bins must obey a variety of configuration con- 
straints. Containment constraints specify which components can go into which 
bins: red bins cannot contain plastic or steel, blue bins cannot contain wood or 
plastic, and green bins cannot contain steel or glass. Capacity constraints specify 
a limit for certain component types for some bins: red bins contain at most one 
wooden component and green bins contain at most two wooden components. 
Finally, requirement constraints specify some compatibility constraints between 
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the components: wood requires plastic, glass excludes copper and copper exclu- 
des plastic. In addition, we are given an initial capacity for each bin, i.e., red 
bins have a capacity of 3 components, blue bins of 1 and green bins of 4 and a 
demand for each component, i.e., 1 glass, 2 plastic, 1 steel, 3 wood, and 2 copper 
components. 



Model binC'genBin.mod" , "genBin.dat") ; 
import enum Colors bin. Colors; 
import enum Components bin. Components ; 
struct Bin { Colors c; int n [Components] ; }; 
int nbBin : = 0 ; 

Open Bin bins[l. .nbBin] ; 
while bin.nextSolutionO do { 
nbBin := nbBin + 1; 
bins . addhO ; 
bins [nbBin] . c := bin.c; 
foralKc in Components) 

bins [nbBin] .n [c] := bin.n[c] ; 

} 

Model proC'chooseBin.mod" , "chooseBin.dat") ; 
if pro.solveO then 

cout « "Solution at cost: " << pro.objectiveValueO « endl; 



Fig. 3. A Script to Solve Vellino’s Problem (vellino . osc) . 



The strategy to solve this problem consists of generating all the possible bin 
configurations and then to choose the smallest number of them that meet the 
demand. This strategy is implemented using a script vellino. osc depicted in 
FigureEland two models genBin.mod and chooseBin.mod depicted in Figures^ 
and|3 It is interesting to study the script in detail at this point. The instructions 

Model binC'genBin.mod" , "genBin.dat") ; 
import enum Colors bin. Colors; 
import enum Components bin. Components ; 



declare the first model and import the enumerated types; these enumerated types 
will be imported by the second model as well. The instructions 

struct Bin { Colors c; int n [Components] ; }; 
int nbBin : = 0 ; 

Open Bin bins[l. .nbBin] ; 

declare a variable to store the number of bin configurations and an open array 
to store the bin configurations themselves. 
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enum Colors . . . ; 
enum Components . . . ; 
int capacity [Colors] = 

int maxCapacity = max(i in Colors) capacityEi]; 
var Colors c; 

var int n [Components] in 0 . .maxCapacity ; 
solve { 

0 < sum(i in Components) n[i] <= capacity[c]; 

c = red => n [plastic] = 0 & n [steel] = 0 & n[wood] <= 1; 

c = blue => n [plastic] = 0 & n[wood] = 0; 

c = green => n [glass] = 0 & n [steel] = 0 & n[wood] <= 2; 

n[wood] >= 1 => n [plastic] >= 1; 

n [glass] = 0 \/ n [copper] = 0; 

n [copper] = 0 \/ n [plastic] = 0; 

}; 



Fig. 4. Generating the Bins in Vellino’s Problem (genBin.mod) . 



import enum Colors; 
import enum Components; 

struct Bin { Colors c; int n [Components] ; }; 

import int nbBin; 

import Bin bin[l. .nbBin] ; 

range R 1.. nbBin; 

int demand [Components] = . . . ; 

int maxDemand = max(c in Components) demand [c]; 

var int produce [R] in 0 .. maxDemand ; 

minimize 

sum(b in R) produce [b] 
subject to 

foralKc in Components) 

sum(b in R) bin[b] ,n[c] * produce [b] = demand [c]; 



Fig. 5. Choosing the Bins in Vellino’s Problem (chooseBin.mod) . 
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The instructions 

while bin.nextSolutionO do { 
nbBin := nbBin + 1; 
bins . addhO ; 
bins [nbBin] . c := bin.c; 
foralKc in Components) 

bins [nbBin] .n[c] := bin.n[c]; 

} 

enumerate all the bin configurations and store them in the bin array in model 
pro. Once this step is completed, the second model is executed and produces a 
solution at cost 8. 

Model genBin.mod specifies how to generate the bin configurations: It is a 
typical constraint program using logical combinations of constraints that should 
not raise any difficulty. Model chooseBin.mod is an integer program that chooses 
and minimizes the number of bins. This model imports the enumerated types as 
mentioned previously. It also imports the bin configurations using the instruc- 
tions 

import int nbBin; 
import Bin bin[l. .nbBin] ; 

It is important to stress to both models can be developed and tested indepen- 
dently since import declarations can be initialized in a data file when a model 
is run in isolation (i.e., not from a script). This makes the overall design com- 
positional. Note also that this model cannot be stated in AMPL which does not 
support sequences of solutions. 

5 Column Generation 

The last two sections have shown how to solve several instances of the same 
model and a sequence of distinct models. This section illustrates how to express 
a column-generation algorithm, Gilmore and Gomory’s cutting stock algorithm, 
that combines and expands these functionalities. In particular, the script uses 
partial linear programming bases to use the optimal basis of an instance as the 
starting point for a (slightly) larger instance. This feature, combined with the 
compositionality and encapsulation provided by OPLScript, makes this script more 
elegant than the traditional AMPL script. 

The problem consists of cutting big wood boards into small shelves to meet 
the customer demands while minimizing the number of boards used. A given 
instance specifies the length of the boards (an integer), the length of the shelves 
(integers), and the demand for each shelf type (integers as well). The comple- 
xity in this application is that it is not practical to generate all the possible 
configurations: in typical applications, there are so many possible cutting con- 
figurations that they cannot even be stored because the boards are large and 
there are many shelves whose sizes may be rather small. The basic idea behind 
the column generation approach consists of starting with a set of configurations 
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data "cut.dat"; 

int+ boardLength : = . . . ; 
int nbShelves := . . . ; 
range Shelves 1 . .nbShelves; 
int shelf [Shelves] := 
int nbConfig := -1; 

Open int+ configEO. .nbConfig, Shelves] ; 
foralKi in Shelves) { 

nbConfig := nbConfig+1; 
config.addhO ; 
foralKj in Shelves) 

config [nbConfig, j] := 0; 
config [nbConfig, i] := boardLength/shelf [i] ; 

} 

Model chooseCC'chooseConf igs .mod" , "cut . dat ") ; 

Model generateCC'generateConf igs .mod" , "cut . dat") ; 
repeat { 

chooseC. solveO ; 

Basis b(chooseC) ; 
foralKi in Shelves) 

generateC . cost [i] := chooseC. meet [i] .dual; 
generateC . solve () ; 

if generateC. objectiveValueO > 1 then { 
nbConfig := nbConfig + 1; 
config.addhO ; 
foralKj in Shelves) 

config [nbConfig,]] := generateC .use [j] ; 
chooseC . reset 0 ; 
chooseC . setBasis (be) ; 
generateC.resetO ; 

} else 
break; 

} until 0; 

range Configs 0.. nbConfig; 

int cutiEp in Configs] := ftoi (ceil (chooseC . cut [p] )) ; 
int obj := sum(p in Configs) cuti[p]; 

cout « "Solution with Cost: " « obj « endl « endl; 



Fig. 6. A Script For Gilmore and Gomory’s Cutting Stock (gomory . osc). 
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and then to use the optimal solution to the (linear relaxation of the) simpli- 
fied problem to generate a new configuration that is promising. In this cutting 
stock application, a column generation consists of solving a knapsack problem: 
the capacity constraint makes sure that a legal configuration is generated, while 
the objective function aims at finding a configuration whose associated variable 
would enter the basis. This process is iterated until no column can be generated. 
The upward rounding of the solution is generally considered of sufficient quality. 



int+ boardLength = . . . ; 
int nbShelves = . . . ; 
range Shelves 1 . .nbShelves; 
int shelf [Shelves] = . . . ; 
int demand [Shelves] = . . . ; 
import int nbConfig; 

import int+ config[0 . .nbConfig, 1 . .nbShelves] ; 
range Configs 0.. nbConfig; constraint meet [Shelves] ; 
var float+ cut [Configs] ; 
minimize 

sum(j in Configs) cut[j] 
subject to 

foralKi in Shelves) 

meet [i] : sum(j in Configs) config[j,i] * cut[j] >= demand[i]; 



Fig. 7 . A Model for Choosing Cutting Stock Configurations (chooseConf igs .mod) . 



Figure 6 depicts a script for this application, while Figures Q and El show 
the models. There are a number of interesting features of OPLScript illustrated in 
this application, as will become clear shortly. The instruction data "cut.dat" 
specifies that the data initializations needed by the script may be found in the 
file cut.dat. The first set of instructions declare an open array config to store 
the configuration and initializes it with a first set of configurations, one for each 
shelf. The second loop is the core of the script. The first two lines 

chooseC . solve 0 ; 

Basis b(chooseC) ; 

select the optimal set of configurations from the subset available and store the 
basis for future reuse. The lines 

foralKi in Shelves) 

generateC . cost [i] := chooseC. meet [i] .dual; 
generateC . solve () ; 

use the dual values to initialize the objective function of the knapsack model, 
since these values correspond to the simplex multipliers. The knapsack model is 
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int+ boardLength = . . . ; 
int nbShelves = . . . ; 
range Shelves 1 . .nbShelves; 
int shelf [Shelves] = . . . ; 
int demand [Shelves] = . . . ; 

Open float cost [Shelves] ; 

var int use[Shelves] in 0. .boardLength; 

maximize 

sum(i in Shelves) cost [i] *use [i] 
subject to 

sum(i in Shelves) shelf [i] * use [i] <= boardLength; 



Fig. 8. A Model for Generating New Cutting Stock Configurations 
(generat eConf igs . mod) 



then solved. If its objective value is greater than one, then its reduced cost is 
negative and thus the variable associated with the generated column will enter 
the basis. The lines 

nbConfig := nbConfig + 1; 
conf ig. addhO ; 
foralKj in Shelves) 

conf ig [nbConfig, j] := generateC .use [j] ; 
chooseC .reset () ; 
chooseC . setBasis (be) ; 
generateC. reset () ; 

add a new configuration using the result of the knapsack, reset the models, and 
use the basis saved previously as starting point for finding a new solution to 
model chooseC that now has an additional variable. The implementation takes 
care of extending this partial basis into a full basis for the extended problem. The 
script terminates when the objective value of the knapsack problem is not greater 
than 1, in which case the linear programming solution is provably optimal. The 
final solution is obtained by rounding up this solution. The two models should 
not raise much difficulty at this point. Note that they can be developed and 
tested in isolation once again. 



6 Controlling Models 

In practical applications, it is often desirable, not only to specify search proce- 
dures as allowed in OPL, but also to control them in order to, say, obtain solutions 
quickly or to produce “good” solutions within reasonable time. This section dis- 
cusses briefly some of the OPLScript support in this area. It is useful to specify that 
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the control discussed in this section is orthogonal to the control of search proce- 
dures. Search procedures and search strategies (e.g., depth-first search, limited- 
discrepancy search, best-first search) can be expressed directly in the OPL model 
and the control discussed here is a form of meta-strategy. 



Model mC'trolleyS.mod") ; 
int fails := 1000; 
m. setFailLimit (fails) ; 
int solved := 0; 
while m.nextSolutionO do { 
solved := 1; 

m. setFailLimit (m. getNumberOf Fails () + fails); 

} 

if solved then { 
m.restoreO ; 

cout « "final solution with makespan: " « m.objectiveValueO « endl; 

} 



Fig. 9. A Script for the Trolley Problem (trolley . osc) . 



Consider the idea of limiting the time devoted to the search of an optimal 
solution by restricting the number of failures, the number of choice points, the 
execution time, or the number of discrepancies between a heuristic and the search 
procedure. Figure 0 depicts a script for an advanced scheduling problem that 
limits the number of failures when searching for a better solution. Similar scripts 
can be written to control execution time or to control a limited discrepancy 
search. The basic idea of the script is to allow for an initial credit of failures 
(say, i) and to search for a solution within these limits. When a solution is found 
with, say, / failures, the search is continued with a limit oii + f failures, i.e., the 
number of failures needed to reach the last solution is increased by the initial 
credit. The instruction 

m. setFailLimit (fails) ; 

specifies that the next call to nextSolution can perform at most fails failures, 
i.e., after fails failures, the execution aborts and nextSolution () returns 0. 
The instruction 

m. setFailLimit (m. getNumberOf Fails 0 + fails); 

retrieves the number of failures needed since the creation of model m and sets a 
new limit by adding fails to this number. The next call to nextSolution takes 
into account this new limit when searching for a better solution. 

Figure E3 shows how to encapsulate this strategy, since it is essentially model- 
independent and can be applied to other models as well. The script features a 
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procedure int limitedFailureSearch(AbstractModel m, int fails) 

{ 

m. setFailLimit (fails) ; 
int solved := 0; 
while m.nextSolutionO do { 
solved := 1; 

m. setFailLimit (m.getNumberOf Fails () + fails); 

} 

if solved then 
m.restoreO ; 
return solved; 

} 

Model trolleyC'trolleyS.mod") ; 

int solved := limitedFailureSearch(trolley , 1000) ; 
if solved then 

cout « "final solution with makespan: " « m.objectiveValueO « endl; 
Fig. 10. The Script for the Trolley Problem Revisited (abstract . osc) . 



procedure declaration whose first parameter is an abstract model. In the script, 
the first parameter receives the trolley model but it could be used for other 
models as well. 

The class of abstract models is a superclass of the model class that encapsula- 
tes all the generic aspects of models. Abstract models are first-class objects that 
can be passed to procedures, be assigned to other abstract models or models, 
and stored in data structures such as sets, arrays, and records. Abstract models 
give a dimension to OPLScript that is missing from AMPL. They make it possible to 
solve the same model for various data files, to run several models with the same 
data files, or, more simply, to execute benchmarking sequences. For instance, it 
is possible to write a script of the form 

setof (string) Models := ...; 
foralKm in Models) { 

AbstractModel a := Model (m, "inst .dat") ; 
a. solveO ; 

cout « "Time: " << a.getTimeO « endl; 

} 

that compares the behaviour of several models on the same instance data. 

7 Conclusion 

This paper was a brief introduction to OPLScript, a script language for compo- 
sing and controlling optimization models. OPLScript was primarily motivated by our 
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desire to simplify the solving of applications that requires solving several in- 
stances of the same model, sequences of models, or a combination of both as in 
column-generation algorithms. By combining high-level data modeling facilities 
of modeling languages with novel abstractions (e.g., models, abstract models, 
basis) to compose and control models, OPLScript may reduce the development time 
of these applications substantially by letting modellers focus on high-level mo- 
deling issues and relieving them from tedious design and implementation effort. 
OPLScript also provides a clear separation of concerns between scripts and models, 
allowing models to be developed, maintained, and tested independently from 
the scripts using them. Finally, OPLScript provides some traditional scripting fun- 
ctionalities over models, e.g., the ability to iterate over a collection of models 
and/or to define procedures whose parameters are abstract models. Future work 
on OPLScript will focus on enhancing the traditional scripting functionalities and on 
code generation. 

Acknowledgments. Comments from the reviewers help improve the presen- 
tation. Thanks also to Irvin Lustig, Janet Lowe, and Jean-Frangois Puget for 
interesting discussions on this paper. 
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Abstract. We study here the well-known propagation rules for Boolean con- 
straints. First we propose a simple notion of completeness for sets of such rules 
and establish a completeness result. Then we show an equivalence in an appro- 
priate sense between Boolean constraint propagation and unit propagation, a form 
of resolution for propositional logic. 

Subsequently we characterize one set of such rules by means of the notion of 
hyper-arc consistency introduced in Mohr & Masini (1988). Also, we clarify the 
status of a similar, though different, set of rules introduced in Simonis (1989) and 
more fully in Codognet & Diaz (1996). 



1 Introduction 

1.1 Motivation 

Boolean constraints form a special case of constraint satisfaction problems in which the 
constraints are defined by means of Boolean formulas. The most common representation 
uses basic constraints that represent the typical connectives, such as and, not etc. 

To reason about Boolean constraints one often uses rules such as: 

“for X A y = z,\f z holds, then both x and y hold” (1) 

or 

“for X V y = z, if X does not hold, then y = z holds.” (2) 

These rules allow us to propagate the information that some values in a Boolean 
constraint are known. This type of inferences have been used for a long time. In McAlle- 
ster (1980) they are explained informally; in McAllester (1990) they are called Boolean 
constraint propagation. In Simonis (1989) such rules are formulated explicitly and used 
to propagate known values through the circuit when generating tests for combinatorial 
circuits. More recently, these rules were used in Codognet & Diaz (1996) as a basis for 
an efficient implementation of a Boolean constraint solver. 

In this paper we put together various simple observations concerning Boolean con- 
straint propagation. The main difficulty lies in a proper setting up of the framework. 
Once this is done the results easily follow. 

To start with, in Section 2, we answer the question in what sense a set of such rules can 
be complete. To this end we introduce a notion of completeness based on the notions of 
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minimal rules and valid rules and show completeness for one set of such rules. In Section 
3 we relate Boolean constraint propagation to unit propagation, a form of resolution for 
propositional logic, by explaining in what sense each method can be simulated by the 
other. 

Next, in Section 4 we introduce proof rules that act on CSP’s. This allows us to 
provide in Section 5 an alternative characterization for one set of rules by means of the 
notion of hyper-arc consistency of Mohr & Masini (1988) (we use here the terminology 
of Marriott & Stuckey (1998)). In Section 6 we clarify the status of another, more 
commonly used, set of such rules given for the and constraint in Simonis (1989) and 
for other connectives in Codognet & Diaz (1996). In the final section we relate Boolean 
constraint propagation to the CHR language of Friihwirth (1995). 



1.2 Preliminaries 

We review here the notions used in the sequel. 

Consider a finite sequence of variables Y := yi, . . ,,yk where A: > 0, with respective 
domains T> := D\, . . Dk associated with them. So each variable yi ranges over the 
domain Di. By a constraint C onY we mean a subset of Z?i x . . . x D^. If C equals 
Di X . . . X Dk, then we say that C is solved. 

Now, by a constraint satisfaction problem, CSP in short, we mean a finite sequence 
of variables X := xi, . . .,Xn with respective domains T> := Di, . . Dn, together with 
a finite set C of constraints, each on a subsequence of X. We write such a CSP as 
(C ; DE), where VE := x\ G Di, . . ,,Xn G Dn and call each construct of the form 
X G D a domain expression. To simplify the notation from now on we omit the “{ }” 
brackets when presenting specific sets of constraints C. 

Consider now an element d := di, . . ., of I?i x ... x and a subsequence 
Y := Xjj , . . ., Xig of X. Then we denote by d[Y] the sequence di^, . . .,di^. By the 
domain ofY we mean the set of all tuples from 79^^ x • • • x Di^. By a solution to 
{C ; xi G Di, . . .,Xn G Dn) we mean an element d G Di x ... x Dn such that for 
each constraint C G C on a sequence of variables X we have d\X] G C. 

Next, we call a CSP failed if some of its domains is empty. Given two CSP’s f and 
■0, we call 0 a reformulation of f if the removal of solved constraints from 0 and ip 
yields the same CSP. We call two CSP’s with the same sequence of variables equivalent 
if they have the same set of solutions. Clearly, two CSP’s such that one is a reformulation 
of another are equivalent. 

Finally, given a constraint c on the variables x\,. . .,Xn with respective domains 
Di, . . ., Dn, and a sequence of domains D[, . . ., D'n such that for i G [l..n] we have 
D'i C Di, we say that c' equals c restricted to the domains D[, . . ., D'^ if c' = cD{D[ x 
...xD'„). 

In this paper we focus on Boolean constraint satisfaction problems. They deal with 
Boolean variables and constraints on them defined by means of Boolean connectives 
and equality. Let us introduce the relevant definitions. 

By a Boolean variable we mean a variable which ranges over the domain which 
consists of two values: 0 denoting false and 1 denoting true. By a Boolean domain 
expression we mean an expression of the form x G D where D C {0, 1}. In what 
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follows we write the Boolean domain expression ccG{l}asa:=l and x G {0} as 
a; = 0. 

In the sequel x, y, z denote different Boolean variables. We distinguish four Boolean 
constraints: 

- X = y,we call it the equality constraint, 

- -'X = y, we call it the NOT constraint, 

- X A j/ = 2; we call it the AA© constraint, 

- X V j/ = 2 ; we call it the OR constraint, 

and interpret them in the expected way. 

Finally, by a Boolean constraint satisfaction problem, in short Boolean CSP, we 
mean a CSP with Boolean domain expressions and each constraint of which is a Boolean 
constraint restricted to the adopted domains. 

For example, the Boolean CSP 

{x Ay = z,^x = y; x = 1, y G {0, 1}, z S {0, 1}) 
can be alternatively written as 



{Ci,C2 ; X = 1,2/ G {0, l},z G {0, 1}), 

where Cl = {(1,1,1), (1,0,0} is a constraint on x, y, z andC 2 = {(1, 0)} is a constraint 
on X, y. 

In this paper we shall relate Boolean constraints to clauses as used in the resolution 
method. The relevant notions are the following ones. 

A literal is a Boolean variable or its negation; a clause is a (possibly empty) disjun- 
ction of different literals. We denote the complement of the literal uhy u.A clause with 
a single literal is called a unit clause. We write m V Q to denote a clause that contains 
the literal m as a disjunct; Q is the disjunction of the remaining literals. 

2 The Proof System BOOL and Its Completeness 

The rules such as the ones given in Section 1 . 1 can be naturally interpreted as implications 
over the constraint formed by the truth table of the connective in question. For instance, 
rule (1) can be viewed as the implication 



z=l— >-x=l, 2 /=l 



over the AND constraint on the variables x, y, z determined by the table: 



X 


y 


z 


Q 


0 


0 


0 


1 


0 


1 


0 


0 


1 


1 


1 
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With this interpretation “completeness” of a set of such rules can be naturally inter- 
preted as the question whether the set implies all other valid rules. These concepts can 
be made precise as follows (see essentially Apt & Monfroy (1999)). 

Definition 1. Consider a constraint C on a sequence of variables VAR, two disjoint 
non-empty subsequences X and Y of VAR, a tuple s of elements from the domain of X 
and a tuple t of elements from the domain ofY. We call X = s ^ Y = t a rule (for C ). 

- We say that X = s ^ Y = t is valid (for C) if for every tuple d G C the equality 

d[X] = s implies the equality d[Y] = t. 

— We say that X = s ^Y = t is feasible ( for C ) if for some tuple d G C the equality 

(i[A] = s holds. 

Suppose that a sequence of variables Z extends X and a tuple of elements u from 
the domain of Z extends s. We say then that Z = u extends X = s. We now say that the 
rule Z = u ^ U = nis implied by the rule X = s ^ Y = t if Z = u extends X = s 
and Y = t extends U = v. 

We call a rule minimal if it is feasible and is not properly implied by a valid rule. 
Finally, we call a set of rules TZfor a constraint C complete if it consists of all minimal 
valid rules for C. □ 

Take for example the AA© constraint. The rule z=l— >^t/=lis implied by the rule 
z = X = l,y = 1. Since both of them are valid, the former rule is not minimal. 
Both rules are feasible, whereas the rule z = 0,a; = l— >^y = 0is not. One can check 
that the rule z = l^x=l,y=l\s minimal. 

Consider now the set of rules presented in Table 1, where for the sake of clarity we 
attached to each implication the Boolean constraint in question. Call the resulting proof 
system BOOL. 

A natural question arises whether some rules have been omitted in the proof system 
BOOL. Observe for example that no rule is introduced for x A y = z when z = 0. In 
this case either x = 0 or y = 0 holds, but x = 0Vy = 0is not a legal conclusion of 
a rule. Alternatively, either x = z or y = z holds, but x = zVy = z is not a legal 
conclusion of a rule either. The same considerations apply to x V y = z when z = 1. 

Also, we noted already that rule AND 6 corresponds to rule (1). In contrast, no rule 
corresponds to rule (2). The following simple result clarifies the situation. 

Theorem 1 (Completeness). For each Boolean constraint the corresponding set of rules 
given in the proof system BOOL is complete. 

Proof. The claim follows by a straightforward exhaustive analysis of the valid rules 
for each considered Boolean constraint. Clearly, such an argument can be mechanized 
by generating all minimal rules for each Boolean constraint. This was done in Apt 
& Monfroy (1999) for the case of arbitrary finite constraints and rules of the form 
X = s ^Y t that have an obvious interpretation. Now, for the case of Boolean 
constraints each domain has two elements, so each rule of the form X = s ^ Y t 
has a “dual” of the form X = s^Y = t' , where t' is obtained from f by a bitwise 
complement. □ 
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Table 1. Proof system BOOL 



EQU 


1 


X 


= 


y 


,x 


= 


-- 1 


~^y = 


: 1 








EQU 


2 


X 


= 


y 


,y 


= 


: 1 


X = 


: 1 








EQU 


3 


X 


= 


y 


,x 


= 


= 0 


~^y = 


: 0 








EQU 


4 


X 


= 


y 


,y 


- 


: 0 


X = 


: 0 








NOT 


1 


— 1 


X 


= 


y, 


X 


= 


l^y 


= 


0 






NOT 


2 


— 1 


X 


= 


y, 


X 


= 


O^y 




1 






NOT 


3 


— 1 


X 


= 


y, 


y 


= 


1 ^ X 


= 


0 






NOT 


4 


— 1 


X 


= 


y, 


y 


= 


0 ^ X 


= 


1 






AND 


1 


X 


A 


y 


= 


z 


X 


= i,y 






2 : = 


= 1 


AND 


2 


X 


A 


y 


= 


z 


X 


= 1,2 


= 


0-> 


y = 


= 0 


AND 


3 


X 


A 


y 


= 


z 


y 


= 1,2 


= 


0 -> 


X - 


= 0 


AND 


4 


X 


A 


y 


= 


z 


X 


= 0 -^ 


2 


= 0 






AND 


5 


X 


A 


y 


= 


z 


y 


= 0 ^ 


2 


= 0 






AND 


6 


X 


A 


y 


= 


z 


z 


= 1 ^- 


X 


= 1 , 


y = 


= 1 


OR 1 




X 


V 


y 


= 


z 


X 


= 1 ^ 


z 


= 1 






OR 2 




X 


V 


y 


= 


z 


X 


= 0,y 




0 ^ 




= 0 


OR 3 




X 


V 


y 


= 


z 


X 


= 0 , 2 


= 


1 


y = 


= 1 


OR 4 




X 


V 


y 


= 


z 


y 


= 0 , 2 


= 




X - 


= 1 


OR 5 




X 


V 


y 


= 


z 


y 


= 1 ^- 


2 


= 1 






OR 6 




X 


V 


y 


= 


z 


z 


= 0 ^- 


X 


= 0 , 


y = 


= 0 



It is useful to mention that the abovementioned program, implemented in ECL®PS'^, 
generated the appropriate rules for the AND constraint in 0.02 seconds and similarly for 
the other three Boolean constraints. 

3 Relation to Unit Propagation 

The considerations of the previous section clarify the matter of completeness. We still 
should explain how the rules of the proof system BOOL are supposed to be applied. To 
this end we consider finite sets of Boolean constraints and literals and interpret the rules 
as proof rules applied to such sets. We illustrate it by means of an example. 

Consider OR 3 rule. We interpret it as the following proof rule: 

xV y = z, ->x, z 
~^x,y,z 

We define now the result of applying a rule of BOOL to a finite set of Boolean 
constraints and literals as expected: an application of the rule results in the replacement of 
(the subset corresponding to) the premise by (the subset corresponding to) the conclusion. 
This interpretation of the rules of BOOL allows us to derive conclusions that coincide 
with the informal use of such rules. In the case of OR 3 rule the constraint xV y = z 
is dropped as no other inference using it can be made, while the literal 2 ; is retained as 
other inferences using it are still possible. 
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In this section we relate so interpreted proof system BOOL to unit propagation, a 
form of propositional resolution (see, e.g. Zhang & Shekel (1996)) that is a component of 
the Davis-Putnam algorithm for the satisfiability problem (see Davis & Putnam (I960)). 
We consider two types of operations on a set of clauses: 

- unit resolution (w.r.t. the literal u): given a unit clause u and a clause uV Q replace 
uV Q by Q, 

- unit subsumption (w.r.t. the literal u)\ given a unit clause u and a clause uV Q delete 
u\/ Q. 

By unit propagation we mean one of the above two operations. 

We now translate each Boolean constraint to a set of clauses as follows. We replace 

- each equality constraint x = y by the clauses x V -^y, -^x V y, 

- each NOT constraint -ix = yby the clauses x V y, -^x V ~<y, 

- sach AND constraint x A y = zby the clauses -ix V -■t/ V 2, x V -^z, y V -iz, 

- each OR constraint xV y = zby the clauses -ix \/ z,-^y \/ z,x V y V -iz. 

Given a finite set of Boolean constraints and literals S we denote by (j>s the resulting 
translation of this set into a set of clauses. It is straightforward to see that this translation 
maintains equivalence. 

In what follows, given two sets of Boolean constraints and literals 5i and S2, we 
write iSi \~bool S 2 to denote the fact that ^2 is obtained by a single application of a 
rule of the BOOL system to 5i, and 5i ^2 to denote the fact that ^2 is obtained 

by up to i applications of the rules of the BOOL system to 5i . 

Analogously, given two sets of clauses (j>i and (f>2, we write (pi \-jjnit (p2 to denote 
the fact that <p2 is obtained by a single application of the unit propagation to <pi, and 
(pi p2 to denote the fact that (p2 is obtained by up to i applications of the unit 

propagation io (pi. 

The following result relates the proof system BOOL to unit propagation. 

Theorem 2 (Reduction 1). Consider two finite sets of Boolean constraints and literals 
Si and 82. Suppose that Si \~bool 82- Then (pg^ 4>S2- 

Proof. We need to analyze each of the 20 rules of BOOL. We illustrate the argument on 
one, arbitrary selected rule, OR 3. 

Suppose that 82 is the result of applying rule OR 5 to 5i. Recall that this rule is 
interpreted as 

xV y = z, -ix, z 
~^x,y,z 

The assumption of this rule translates to the following set of clauses: 

{-ix V z, -ly V z, X V y V ~<z, ~<x, z}. 

By the application of the unit resolution w.r.t. z we obtain the set 



{-ix V z,-<y V z,x V y, ~<x, z}, 
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from which by two applications of the unit subsumption w.r.t. 2 : we obtain the set 

{x V y, -ix, z}. 

By the application of the unit resolution w.r.t. we now obtain the set 

{^x,y,z} 

which corresponds to the conclusion of rule OR 3. 

For other rules the argument is equally straightforward. □ 

The converse relation is a bit more complicated since to translate clauses to Boolean 
constraints we need to use auxiliary variables. First, we translate each expression of the 
form Q = z, where Q is a clause and z a variable, to a finite set of Boolean constraints 
and literals. We proceed by induction on the number of literals in Q. 

If Q is a unit clause, then Q = z is either an equality constraint or a NOT constraint 
and we put trans{Q = z) := {Q = z}. Otherwise Q is of the form uV Qi and we 
define 

trans{x V Qi = z) := {x V y = z} U trans{Qi = y), 
where y is a fresh variable, 

trans{->x V Qi = z) := {->x = u, u V y = z} U trans{Q\ = y), 

where v and y are fresh variables. 

Finally, we put for a unit clause u 

trans{u) := {u}, 

and for a non-unit clause Q 

trans{Q) := {z} U trans{Q = z), 
where z is a fresh variable. 

Note that for a non-unit clause Q the resulting finite set of Boolean constraints and 
literals trans{Q) depends on the order in which the literals of Q are selected and on 
the specific choice of fhe fresh variables, so it is not uniquely determined. However, it is 
clear that for each such translation trans{Q), the clause Q is equivalent to 3ztrans{Q), 
where z is the sequence of the introduced fresh variables. 

Given now a finite set of clauses (p we translate each of its clauses separately and call 
thus obtained finite set of Boolean constraints and literals a translation of (j> to a finite 
set of Boolean constraints and literals. 

Below, given two sets of Boolean constraints and literals C and S we say that C 
semantically follows from a set S if every valuation that satisfies S can be exfended fo 
a valuation fhat satisfies C. 

We fhen have fhe following result. 

Theorem 3 (Reduction 2). Consider two finite sets of clauses <j>i and </> 2 . Suppose that 
4>i ^UNiT 4 > 2 - Then for some translations 5i and S 2 of (pi and (p 2 to finite sets of 
Boolean constraints and literals and some set of Boolean constraints and literals C we 
have iSi S 2 U C, where C semantically follows from 82 . 
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Informally, the reduction from 5i to S 2 yields additionally some redundant set of Boolean 
constraints and literals C. 

Proof. Consider first the unit resolution. It leads to a replacement of m V Q by Q in 
presence of the unit clause u. Suppose that u is a Boolean variable x. Then u is -^x. 

We now have for some fresh variables v, y and 2 ; 

trans{->x V Q) = {z} U {~<x = v,v\/ y = z}U trans{Q = y). 

So the clauses x and -ix V Q translate to the set of Boolean constraints and literals 

{x, z, ->x = v,v y y = z} \J trans{Q = y). 

By the application of the NOT 1 rule we now obtain the set 

{x, z, -IV, V V y = z}U trans{Q = y), 

from which by the OR 3 rule we obtain 

{x,z,-iv,y}Otrans{Q = y). (3) 

Now, if Q is a unit clause, then the set (3) equals 

{x,z,-iv,y,Q = y} 

from which we get by the EQU 2 rule 

{x,z,^v,y,Q}, 

i.e., the set trans{x) U trans{Q) U {z, ~iv, y}. Since v, y and z are fresh, {z, ~iv, y} 
semantically follows from trans{x) U trans{Q). 

If Q is a non-unit clause we can assume that 

trans{Q) = {y} U trans{Q = y), 

so the set (3) equals trans{x) U trans{Q) U {z, -i?;}. Since v and z are fresh, {z, -iw} 
semantically follows from trans{x) U trans{Q). 

The argument in case u is negation of a Boolean variable is even more straightforward. 



Consider now the unit subsumption. It leads to a deletion of the clause uV Q in 
presence of the unit clause u. Suppose that u is ~ix for some Boolean variable x. We 
have for some fresh variables v, y and z 

trans{-ix V Q) = {z, ~ix = v,v\/ y = z}U trans{Q = y). 

So the clauses -ix and -ix V Q translate to the set of Boolean constraints and literals 

{-ix, z, -ix = v,v y y = z} \J trans{Q = y). 
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By the application of the NOT 2 rule we now obtain the set 

{-'X, z,v,vy y = z}0 trans{Q = y), 
from which by the OR 1 rule we obtain 

{-■a;, z, u} U trans{Q = y). 

It is now easy to see that the set {z, u} U trans{Q = y) semantically follows from 
{-ix}. Indeed, a straightforward proof by induction shows that for any clause Q the set 
trans{Q = y) is satisfiable. □ 

The above two results clarify the relationship between Boolean constraint propaga- 
tion and unit propagation. They show that each method can be simulated by another in 
constant time, albeit the simulation of the unit propagation by means of the Boolean 
constraint propagation leads to a generation of redundant constraints. 

A relation between Boolean constraint propagation and the Davis-Putnam algorithm 
was already mentioned in McAllester (1980, page 1), where it is stated without any 
further explanation that “propositional [i.e., Boolean] constraint propagation [...] was 
originally described, in essence, by Davis & Putnam (1960) ”. But to our knowledge this 
connection was not made precise. 



4 A Proof Theoretic Framework 

We now proceed towards another characterization of the proof system BOOL in constraint 
processing terms. In the previous section we considered finite sets of Boolean constraints 
and literals. We now need to translate them into Boolean CSP’s by interpreting in an 
appropriate way the literals belonging to such a set. 

Given a Boolean variable x there are four sets of literals concerning x. We interpret 
each of them as a Boolean domain expression, as follows: 

- 0 by X G {0, 1}, 

- {x} by X G {!}, 

- {-'x} by X G {0}, 

- {x, -ix} by X G 0. 

This interpretation entails a translation of finite sets of Boolean constraints and 
literals to Boolean CSP’s. For example, the set {xV y = z, -ix, z} (that corresponds to 
the premise of OR 3 rule) translates to the Boolean CSP 

{xV y = z; X G {0},y G {0, l},z G {!}). 

It is straightforward to see that this translation preserves equivalence in the sense 
that {di, . . dn) is a solution to a Boolean CSP V := {C ] xi G I?i, . . ., x„ G D„) iff 
the assignment (xi/di, . . ., Xn/dn) satisfies fhe original set of Boolean constraints and 
literals. 
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This translation also leads to another interpretation of the rules of the proof system 
BOOL. We interpreted them as rules on the finite sets of Boolean constraints and literals. 
By means of the above translation they become rules on Boolean CSP’s. 

Note that for a set L of literals concerning x that translates into the Boolean domain 
expression x G D, the set L U {x} translates into the Boolean domain expression 
X G Z? n {!}, and similarly for the literal -ix. Consequently, the rule 



~^x = y,y = Q^x = l, 



translates into 

{-nx = y; X G Dx,y = 0) 

( ; xG D^n {!},?/ = 0 ) 

and the rule 

X Ay = z, z = 1— >-x = l,y = 1, 

translates into 

{x Ay = z ; x G Dx,y G Dy,z = 1) 

( ; X G D^n {l},y G DyC\ = 1) 

In addition the rule 

xVy = z,x = 0^y=z, 

that naturally corresponds to rule (2) of in Section 1.1, translates into 



{xV y = z] x = 0,y G Dy, z G Dz) 
{y = z] X = 0,y G Dy,z G D^) 



This brings us to the proof theoretic framework introduced in Apt (1998). We briefly 
recall the relevant definitions. The crucial concept that we need is that of a CSP being 
closed under the applications of a proof rule. In the above paper we introduced two types 
of proof rules for CSP’s: deterministic and splitting. Here we only use the deterministic 
ones. These rules are of the form 

</> 






where (p and tp are CSP’s. 

Consider now a CSP of the form (C U Ci ; 'DU'Di) and a deterministic rule of the 
form 



{Cl ; Vi) 
{C2 ; V 2 ) 



(4) 



We then say that rule (4) can be applied to (C U Ci ; VOVi) and call 



(CUC2 ; VOV2) 

the result of applying it to {CUCi ; 22 U Pi) . If (C U C 2 ; P U P 2 ) is not a reformulation 
of (C U Cl ; P U Pi), then we say that it is the result of a relevant application of rule 
{A) to (CUCi ; PUPi). 

Finally, given a CSP </> and a deterministic rule R, we say that p is closed under 
the applications of R if either R cannot be applied to p or no application of it to p is 
relevant. 
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Take for example the Boolean CSP 4> := {x A y = z ; x = l,y = 0, z = 0). This 
CSP is closed under the applications of the rule 

{x Ay = z; x=l,y € Dy, z € D^) 

{y = z] X = l,y G Dy,z G D^) 

Indeed, this rule can be applied to <f)-, the outcome ist/’:= {y = z; x = l,y = 0, z = 0). 
After the removal of solved constraints from </> and ip we get in both cases the solved 
CSP(0; x=l,y = 0,z = 0). 

In contrast, the Boolean CSP <p := {x Ay = z ; x = l,y € {0, 1}, 2 ; G {Oj 1}) 
is not closed under the applications of the above rule because {y = z ; x = l,y G 
{0, 1}, 2 : G {0, 1}) is not a reformulation of (p. 

In what follows we identify the rules of the proof system BOOL with their counter- 
parts that act on Boolean CSP’s. At this stage we introduced two interpretations of the 
rules of the proof system BOOL: one on the hnite sets of Boolean constraints and literals 
and the other on Boolean CSP’s. It is straightforward to check that these interpretations 
correspond in the following sense. Consider two finite sets of Boolean constraints and 
literals 5i and S 2 that translate respectively to the Boolean CSP’s V\ and V 2 and a rule 
r of BOOL. Then in the hrst interpretation r transforms 5i into ^2 iff in the second 
interpretation it transforms V\ into V 2 ■ 

It is worthwhile to note that the Characterization Theorem 4 can be proved indirectly 
by using the theoretical results established in Apt & Monfroy (1999) together with the 
output of the already mentioned in Section 2 program that automatically generates proof 
rules from the truth tables, or more generally, from a table representing a hnite constraint. 



5 Relation to Hyper-arc Consistency 

We now return to CSP’s. In Mohr & Masini (1988) a generalization of the notion of arc 
consistency of Mackworth (1977) from binary constraints to arbitrary constraints was 
introduced. Let us recall the dehnition. 

Definition 2. 

- A constraint C is called hyper-arc consistent if for every variable of it each value in 
its domain participates in a solution to C. 

- A CSP is called hyper-arc consistent if every constraint of it is. □ 

The following result characterizes the proof system BOOL in terms of the notion of 
hyper-arc consistency for Boolean CSP’s. 

Theorem 4 (Characterization). A non-failed Boolean CSP is closed under the appli- 
cations of the rules of the proof system BOOL iff it is hyper-arc consistent. 

Proof. Let f be the CSP under consideration. Below C := x A y = z is some AND 
constraint belonging to f. We view it as a constraint on the variables x, y, z. Let D^, Dy 
and Dz be respectively the domains of x,y and z. 

( ^ ) Consider the AND constraint C. We have to analyze six cases. 
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Case 1. Suppose 1 G D^;. 

Assume that neither (1, 1) G DyXDz nor(0,0) G x . Then either = {1} 
and Dz = {0} or Dy = {0} and = {!}. 

If the former holds , then by the AND 3 rule we get = { 0 } which is a contradiction. 
If the latter holds, then by the AND 5 rule we get Dz = {0} which is a contradiction. 
We conclude that for some d we have (l,d,d) G C. 

Case 2. Suppose 0 G D^. 

Assume that 0 ^ Dz- Then Dz = {!}, so by the AND 6 rule we get = {1} 
which is a contradiction. Hence 0 G Dz . Let now d be some element of Dy . We then 
have (0, d, 0) G C. 

Case 3. Suppose 1 G Dy. 

This case is symmetric to Case 1. 

Case 4. Suppose 0 G Dy. 

This case is symmetric to Case 2. 

Case 5. Suppose 1 G Dz. 

Assume that (1, 1) ^ D^ x Dy. Then either D^ = {0} or Dy = {0}. If the former 
holds, then by the AND 4 rule we conclude that Dz = {0}. If the latter holds, then 
by the AND 5 rule we conclude that Dz = {0}. For both possibilities we reached a 
contradiction. So both 1 G D^; and 1 G Dy and consequently (1,1,1) G C. 

Case 6. Suppose 0 G Dz. 

Assume that both D^ = {1} and Dy = {!}. By the AMD 1 rule we conclude that 
Dz = {1} which is a contradiction. So either 0 G D^ or 0 G Dy and consequently for 
some d either (0, d, 0) G C or {d, 0, 0) G C. 

(<=) We need to consider each rule in turn. We analyse here only the AND rules. For 
other rules the reasoning is similar. 

AND 1 rule. 

Suppose that = {IjandUy = {Ij.IfO G Hz, then by the hyper-arc consistency 
for some d\ G D^ and d 2 G Dy we have {d\, c? 2 , 0) G C, so (1, 1, 0) G C which is a 
contradiction. 

This shows that Dz = {1} which means that <j) is closed under the applications of 
this rule. 

AND 2 rule. 

Suppose that Hj, = {1} and Hz = {Oj.Ifl G Hj,, then by the hyper-arc consistency 
for some di G D^ and d 2 G Hz we have {di, 1, (^ 2 ) G C, so (1,1,0) G C which is a 
contradiction. 

This shows that Dy = {0} which means that (p is closed under the applications of 
this rule. 

AND 3 rule. 

This case is symmetric to that of the AND 2 rule. 
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AND 4 rule. 

Suppose that = {0}. If 1 G D^, then by the hyper-arc consistency for some 
di G D^andd 2 G Dy wehave (di, c/ 2 , 1) G C,so(l,l,l) G C which is a contradiction. 

This shows that = {0} which means that <j) is closed under the applications of 
this rule. 



AND 5 rule. 

This case is symmetric to that of the AND 4 rule. 

AND 6 rule. 

Suppose that = {1}. If 0 G D^, then by the hyper-arc consistency for some 
di G Dy and c ?2 G we have (0, di, c? 2 ) G C, so 0 G which is a contradiction. 

This shows that = {!}. By a symmetric argument also Dy — {1} holds. This 

means that (f> is closed under the applications of this rule. 



An analogous reasoning can be spelled out for the equality, OR and NOT constraints 
and is omitted. 



□ 



Note that the restriction to non-failed CSP’s is necessary: the failed CSP {x A y = 
z ; a; G 0, y G {0, 1}, z G {0, 1}) is not hyper-arc consistent but it is closed under the 
applications of the rules of BOOL. 

It is also easy to check that all the rules of the BOOL system are needed, that is, this 
result does not hold when any of these 20 rules is omitted. For example, if rule AND 4 
is left out, then the CSP {x A y = z ; x = 0, y G {0, 1}, z G {0, 1}) is closed under the 
applications of all remaining rules but is not hyper-arc consistent. 

In view of the fact that all considered proof rules preserve equivalence, the above 
theorem shows that to reduce a Boolean CSP to an equivalent one that is either failed or 
hyper-arc consistent it suffices to close it under the applications of the rules of the BOOL 
system. This provides a straightforward algorithm for enforcing hyper-arc consistency 
for Boolean constraints. We shall return to this point in the final section. 



6 The Proof System of Codognet and Diaz 

Usually, slightly different proof rules are introduced when dealing with Boolean con- 
straints. For example, in Codognet & Diaz (1996) the set of rules given in Table 2 is 
considered. We call the resulting proof system BOOL’. 

To be precise, the rules EQU are not present in Codognet & Diaz (1996). Instead, 
the constraints 0 = 0 and 1 = 1 are adopted as axioms. Note that rules AND 1 AND 
2’, OR 2 ’and OR 5 ’introduce constraints in their conclusions. OR 2 ’rule corresponds 
to rule (2) of Section 1.1. 

The main difference between BOOL and BOOL’ lies in the fact that the rules AND 
1-3 of BOOL are replaced by the rules AND 1 ’ and AND 2 ’ of BOOL’ and the rules OR 
2=^ of BOOL are replaced by the rules OR 2 ’ and OR 3 ’ of BOOL’. (The fact that the rule 
AND 6 of BOOL is split in BOOL’ into two rales, AND 3 ’ and AND 6 ’ and analogously 
for the rules OR 6 of BOOL and OR 3 ’ and OR 6 ’ of BOOL’ is of no importance.) 
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Table 2. Proof system BOOL’ 



EQU 1 


— 4 as in the system BOOL 


NOT 1 


— 4 as in the system BOOL 


AND 1' 


X Ay = z,x = l^y = z 


AND 2' 


X A y = z,y — 1 ^ X = z 


AND S' 


xAy = z,z = l^x = l 


AND 4 


as in the system BOOL 


AND 5 


as in the system BOOL 


AND 6' 


xAy = z,z = l^y— 1 


OR 1 


as in the system BOOL 


OR 2' 


x\/y = z,x = 0^y = z 


OR S' 


xVy = z,y — 0^x = z 


OR 4' 


xVy = z,z = 0—^x = 0 


OR 5 


as in the system BOOL 


OR 6' 


xVy = z,z = 0^y — 0 



The AA® rules of the fiOOL’ system can he found (in a somewhat different format) in 
Simonis (1989). A natural question arises whether the proof systems BOOL and BOOL’ 
are equivalent. The precise answer is “sometimes”. First, observe that the following 
result holds. 

Theorem 5. If a non-failed Boolean CSP is closed under the applications of the rules 
of the proof system BOOL’, then it is hyper-arc consistent. 

Proof. The proof relies on the following immediate observation. 

Claim Consider a Boolean CSP f containing the AND constraint x A y = z on the 
variables x,y,z with respective domains D^jDy and D^. If f is closed under the 
applications of the AND I’ rule, then = {1} implies Dy = Dz- Iff A closed under 
the applications of the AND 2’ rule, then Dy = {1} implies = Dz- □ 

Suppose now that the CSP in question contains the AND constraint x A y = z on 
the variables x,y,z with respective domains D^, Dy and Dz- We present the proof only 
for the cases where the argument differs from the one given in the proof of the hyper-arc 
consistency Theorem 4. 

Case 1. Suppose 1 G D^. 

Assume that neither (1, 1) G DyXDz nor(0,0) G x . Then either = {1} 
and Dz = {0} or Dy = {0} and Dz = {!}. 

If the former holds, then by Claim 1 Dy = Dz, which is a contradiction. If the latter 
holds, then by the AA® 5 rule Dz = {0} which is also a contradiction. We conclude that 
for some d we have (l,d,d) G C. 



Case 6. Suppose 0 G Dz- 
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Assume that both = {1} and Dy = {!}. By Claim 1 Dy = D^, which is 
a contradiction. So either 0 G or 0 G Dy and consequently for some d either 
(0,d,0) G Cor (d,0,0) G C. 

The reasoning for other Boolean constraints is analogous and omitted. □ 

In contrast to the case of the BOOL system the converse result does not hold. Indeed, 
just take the CSP (j) := {x A y = z ; x = 1, y G {0, 1}, z G {0, 1}). Note that 4> is 
hyper-arc consistent but it is not closed under the applications of the AND 1 ’ rule. 

In general, there are four such “problematic” CSP’s. In each of them the single AA© 
or OR constraint can be reduced to an equality constraint. These four CSP’s are used in 
the following definition. 

Definition 3. We call a Boolean CSP limited if none of the following four CSP’s forms 
a subpart of it: 

- {x A y = z ; X = l,y G {0,1}, z G {0, 1}), 

- {xAy = z-, xG {0, l},j/= l,zG {0,1}), 

- {x \/ y = z ] X = 0,y G {0,1}, z G {0, 1}), 

- (xVy = z; xG {0, l},j/ = 0,zG (0, 1}). □ 

The idea is that if we exclude these “problematic” CSP, then hopefully we prevent 
the situation that a CSP is hyper-arc consistent but is not closed under the applications of 
the AND 1 ’ (respectively AND 2 OR 2 ’ or OR 3 } rule. This is exactly what the following 
theorem states. 

Theorem 6. If a non-failed Boolean CSP is limited and hyper-arc consistent, then it is 
closed under the applications of the rules of the proof system BOOL’. 

Proof. In view of the hyper-arc consistency Theorem 4 we only have to consider the rules 
of BOOL’\h&t are absent in BOOL. We present here an argument for one representative 
rule. 

AND 1 ’ rule. 

Suppose that = (Ij. If 0 G Dy, then by the hyper-arc consistency for some 
d G Dz we have (1, 0, fi) G C, which means that 0 G Dz. Conversely, if 0 G Dz, then 
by the hyper-arc consistency for some d G Dy we have (1, d, 0) G C, so 0 G Dy. By a 
similar argument we get that 1 G Dy iff 1 G Dz. This shows that Dy = Dz- 

By assumption f is limited, so either Dy f (0, 1} or Dz f (0, 1}. Hence either 
Dy = Dz = {1} or Dy = Dz = (Oj. In both cases the CSP under consideration is 
closed under the applications of the AND 1 ’ rule. □ 

To summarize: for Boolean CSP’s that are limited the respective closures under the 
rules of the proof systems BOOL and BOOL’ coincide. 

7 Relation to the CHR Language 

The rules such as the ones given in the proof system BOOL can be straightforwardly 
represented as so-called simplification rules of the CHR language of Friihwirth (1995). 
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The CHR language is part of the ECL*PS'^ system (see A. Aggoun et al. (1995)). For a 
more recent and more complete overview of CHR see Friihwirth (1998). For example 
AND 6 rule, so 

X Ay = z, z = 1— = l,y = 1, 



is written in the syntax of CHR as 

and(X, Y, Z) <=> Z=l|X=l,Y=l. 

In fact, such CHR rules for the AND constraint can be already found in Friihwirth, 
Herold, Kiichenhoff, Provost, Fim, Monfroy & Wallace (1992). They amount to the cor- 
responding AND rules of the BOOL’ system. Boolean constraints form a prime example 
for an effective use of CHRs. A CHR program that corresponds to the proof system BOOL 
or BOOL’ when combined with a labeling procedure constitutes a natural decision pro- 
cedure for Boolean CSP’s. The Characterization Theorem 4 shows that the CHR rules 
corresponding to the BOOL system implement hyper-arc consistency. 



8 Conclusions 

In this paper we collected a number of simple but hopefully useful observations on 
Boolean constraint propagation rules. First of all, we clarified in what sense one set of 
such rules is complete. Then we showed that Boolean constraint propagation is in fact 
equivalent to unit propagation, a form of resolution for propositional logic. The reduction 
in each direction can be achieved in constant time. 

This shows that given a combinatorial problem that can be naturally formalized 
using Boolean constraints (for example, a problem concerning combinatorial circuits) 
it is useless to translate it to a clausal form and subsequently employ unit propagation: 
in such case Boolean constraint propagation achieves the same effect. Conversely, it is 
useless to translate a clausal form representation to a representation that uses Boolean 
constraints with the aim of employing Boolean constraint propagation: in this case unit 
propagation achieves the same effect. 

The subsequent characterization of the introduced set of Boolean constraint propa- 
gation rules by means of the hyper-arc consistency notion shows that this set of rules is in 
some sense optimal. The notion of hyper-arc consistency also allowed us to differentiate 
between two sets of such rules proposed in the literature. 

Acknowledgement. We thank Rina Dechter, Thom Friihwirth and the referees for hel- 
pful comments. 
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Abstract. We propose an abstraction scheme for soft constraint pro- 
blems and we stndy its main properties. Processing the abstracted ver- 
sion of a soft constraint problem can help us in many ways: for example, 
to find good approximations of the optimal solutions, or also to provide 
us with information that can make the subsequent search for the best 
solution easier. The results of this paper show that the proposed scheme 
is promising; thus they can be used as a stable formal base for any expe- 
rimental work specific to a particular class of soft constraint problems. 



1 Introduction 

Classical constraint satisfaction problems (CSPs) fS| are a very convenient and 
expressive formalism for many real-life problems, like scheduling, resource al- 
location, vehicle routing, timetabling, and many others However, many of 
these problems are often more faithfully represented as soft constraint satis- 
faction problems (SCSPs), which are just like classical CSPs except that each 
assignment of values to variables in the constraints is associated to an element 
taken from a partially ordered set. These elements can then be interpreted as 
levels of preference, or costs, or levels of certainty, or many other criteria. 

There are many formalizations of soft constraint problems. In this paper 
we consider the one based on semirings m, where the semiring specifies the 
partially ordered set and the appropriate operation to use to combine constraints 
together. 

Although it is obvious that SCSPs are much more expressive than classical 
CSPs, they are also more difficult to process and to solve. Therefore, sometimes it 
may be too costly to find all, or even only one, optimal solution. Also, although 
classical propagation techniques like arc-consistency HZ| can be extended to 
SCSPs 0, even such techniques can be too costly to be used, depending on the 
size and structure of the partial order associated to the SCSP. 

For these reasons, it may be reasonable to work on a simplified version of the 
given problem, trying however to not loose too much information. We propose to 
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define this simplified version by means of the notion of abstraction, which takes 
an SCSP and returns a new one which is simpler to solve. Here, as in many 
other works on abstraction [m, “simpler” may mean many things, like the 
fact that a certain solution algorithm finds a solution, or an optimal solution, in 
a fewer number of steps, or also that the abstracted problem can be processed 
by a machinery which is not available in the concrete context. 

There are many formal proposals to describe the process of abstracting a 
notion, be it a formula, or a problem m, or even a classical PH or a soft CSP 
m- Among these, we chose to use one based on Galois insertions 0, mainly 
to refer to a well-know theory, with many results and properties that can be 
useful for our purposes. This made our approach compatible with the general 
theory of abstraction in m- Then, we adapted it to work on soft constraints: 
given an SCSP (the concrete one), we get an abstract SCSP by just changing 
the associated semiring, and relating the two structures (the concrete and the 
abstract one) via a Galois insertion. Note that this way of abstracting constraint 
problems does not change the structure of the problem (the set of variables 
remains the same, as well as the set of constraints), but just the semiring values 
to be associated to the tuples of values for the variables in each constraint. 
Once we get the abstracted version of a given problem, we propose to 

1. process the abstracted version: this may mean either solving it completely, 
or also applying some incomplete solver which may derive some useful infor- 
mation on the abstract problem; 

2. bring back to the original problem some (or possibly all) of the information 
derived in the abstract context; 

3. continue the solution process on the transformed problem, which is a concrete 
problem equivalent to the given one. 

All this process has the main aim of finding an optimal solution, or an appro- 
ximation of it, for the original SCSP, within the resource bounds we have. The 
hope is that, by following the above three steps, we get to the final goal faster 
than just solving the original problem. 

A deep study of the relationship between the concrete SCSP and the corre- 
sponding abstract one allows us to prove some results which can help in deriving 
useful information on the abstract problem and then take some of the derived 
information back to the concrete problem. In particular, we can prove the follo- 
wing: 

— If the abstraction satisfies a certain property, all optimal solutions of the 
concrete SCSP are also optimal in the corresponding abstract SCSP (see 
Theorem EJ. Thus, in order to find an optimal solution of the concrete pro- 
blem, we could find all the optimal solutions of the abstract problem, and 
then just check their optimality on the concrete SCSP. 

— Given any optimal solution of the abstract problem, we can find upper and 
lower bounds for an optimal solution for the concrete problem (see Theorem 
EJ. If we are satisfied with these bounds, we could just take the optimal 
solution of the abstract problem as a reasonable approximation of an optimal 
solution for the concrete problem. 



110 



S. Bistarelli et al. 



— If we apply some constraint propagation technique over the abstract problem, 
say P, obtaining a new abstract problem, say P' , some of the information in 
P' can be inserted into P, obtaining a new concrete problem which is closer 
to its solution and thus easier to solve (see Theorem 0 and 0 • 

This however can be done only if the semiring operation which describes how 
to combine constraints on the concrete side is idempotent (see Theorem 01 . 

— If instead this operation is not idempotent, still we can bring back some 
information from the abstract side. In particular, we can bring back the 
inconsistencies (that is, tuples with associated the worst element of the se- 
miring), since we are sure that these same tuples are inconsistent also in the 
concrete SCSP (see TheoremEI). 

In both the last two cases, the new concrete problem is easier to solve, in the 
sense, for example, that a branch-and-bound algorithm would explore a smaller 
(or equal) search tree before finding an optimal solution. 

The paper is organized as follows. First, in Section 0 we give the necessary 
notions about soft CSPs and abstraction. Then, in Section 0we define our notion 
of abstraction, and in Section 0 we prove properties of our abstraction scheme 
and discuss some of their consequences. Finally, in Section Q we summarize our 
work and give hints about future directions. 



2 Background 

In this section we recall the main notions about soft constraints 0 and abstract 
interpretation 0, that will be useful for the developments and results of this 
paper. 



2.1 Soft Constraints 



In the literature there are many formalizations of the concept of soft constraints 
Here we refer to the one described in 



n which however can be 
shown to generalize and express many of the others m- In a few words, a soft 
constraint is just a classical constraint where each instantiation of its variables 
has an associated value from a partially ordered set. Combining constraints will 
then have to take into account such additional values, and thus the formalism 
has also to provide suitable operations for combination (x) and comparison (-I-) 
of tuples of values and constraints. This is why this formalization is based on 
the concept of semiring, which is just a set plus two operations. 



Definition 1 (semirings and c-semirings). A semiring is a tuple x, 

0,1) such that: 

— A is a set and 0, 1 S A; 

— + is commutative, associative and 0 is its unit element; 

— X is associative, distributes over +, 1 is its unit element and 0 is its absor- 
bing element. 
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A c-semiring is a semiring (A,+, x,0, 1) such that: + is idempotent with 1 as 
its absorbing element and x is commutative. 

Let us consider the relation <s over A such that a <s b iS a + b = b. Then 
it is possible to prove that (see 0): 

— <s is a partial order; 

— + and X are monotone on <5; 

— 0 is its minimum and 1 its maximum; 

“ {A, <s) is a complete lattice and, for all a, b G A, a + b = lub{a, b). 

Moreover, if x is idempotent, then {A, <5) is a complete distributive lattice and 
X is its gib. Informally, the relation <s gives us a way to compare (some of the) 
tuples of values and constraints. In fact, when we have a <s b, we will say that 
b is better than a. 

Definition 2 (constraints). Given a c-semiring S = (A, +, x,0, 1), a finite 
set D (the domain of the variables) , and an ordered set of variables V, a con- 
straint is a pair {def, con) where con C V and def : — >■ A. 

Therefore, a constraint specifies a set of variables (the ones in con), and as- 
signs to each tuple of values of D of these variables an element of the semiring set 
A. This element can then be interpreted in several ways: as a level of preference, 
or as a cost, or as a probability, etc. The correct way to interpret such elements 
depends on the choice of the semiring operations. 

Constraints can be compared by looking at the semiring values associated to 
the same tuples: Consider two constraints c\ = (defi,con) and C 2 = {def 2 , con), 
with |con| = k. Then c\ C5 C 2 if for all k-tuples t, defift) <5 def 2 {t). The rela- 
tion Cs is a partial order. In the following we will also use the obvious extension 
of this relation to sets of constraints, and also to problems (seen as sets of con- 
straints). Therefore, given two SCSPs Pi and P 2 with the same graph topology, 
we will write Pi Cg P 2 if, for each constraint ci in P and the corresponding 
constraint C 2 in P 2 , we have that Ci Cg C 2 . 

Definition 3 (soft constraint problem). A soft constraint satisfaction pro- 
blem (SCSP) is a pair {C, con) where con C V and C is a set of constraints. 

Note that a classical CSP is a SCSP where the chosen c-semiring is: 

Scsp = {{false, true}, y ,t\, false, true). 

Fuzzy CSPs I8ll9l20l can instead be modeled in the SCSP framework by 
choosing the c-semiring: 

Spcsp = ([0) 1], maa;, min, 0, 1). 

Figure n shows a fuzzy CSP. Variables are inside circles, constraints are repre- 
sented by undirected arcs, and semiring values are written to the right of the 
corresponding tuples. Here we assume that the domain D of the variables con- 
tains only elements a and b. 
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a... 0.9 


a... 0.9 


b...0.1 


b... 0.5 






aa . 


.0.8 


ab . 


.0.2 


ba . 


.0 


bb . 


.0 



Fig. 1. A fuzzy CSP. 

Definition 4 (combination). Given two constraints Ci = {defi,coni) and 
C 2 = (def 2 ,con 2 ), their combination ci 0 C 2 is the constraint {def,con) defined 
by con = coni U con 2 and def{t) = defiit iconi) ^ def 2 {t icon2fl- combina- 
tion operator 0 can be straightforward extended also to sets of constraints: when 
applied to a set of constraints C , we will write C. 

In words, combining two constraints means building a new constraint invol- 
ving all the variables of the original ones, and which associates to each tuple of 
domain values for such variables a semiring element which is obtained by mul- 
tiplying the elements associated by the original constraints to the appropriate 
subtuples. 

Using the properties of x and -I-, it is easy to prove that: 

— 0 is associative, commutative, and monotone over Cg; 

— if X is idempotent, 0 is idempotent as well. 



Definition 5 (projection). Given a constraint c = (def,con) and a subset I 
ofV, the projection ofc over I, written c (1/, is the constraint {def, con') where 
con' = con fl I and def'{t') = =t' def{t). 

Informally, projecting means eliminating some variables. This is done by 
associating to each tuple over the remaining variables a semiring element which is 
the sum of the elements associated by the original constraint to all the extensions 
of this tuple over the eliminated variables. 

Definition 6 (solution). The solution of a SGSP problem P = (C,con) is the 
constraint Sol{P) = {^C) JJ-con- 

That is, to obtain the solution of an SCSP, we combine all constraints, and 
then project over the variables in con. In this way we get the constraint over con 
which is “induced” by the entire SCSP. 

For example, each solution of the fuzzy CSP of Figure Q] consists of a pair 
of domain values (that is, a domain value for each of the two variables) and 
an associated semiring element (here we assume that con contains all variables) . 

^ By t fy "'S mean the projection of tuple t, which is defined over the set of variables 
X, over the set of variables V C X. 
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Such an element is obtained by looking at the smallest value for all the subtuples 
(as many as the constraints) forming the pair. For example, for tuple (a, a) (that 
is, X = y = a), we have to compute the minimum between 0.9 (which is the value 
for X = a), 0.8 (which is the value for {x = a,y = a)) and 0.9 (which is the value 
for y = a). Hence, the resulting value for this tuple is 0.8. 

Definition 7 (optimal solution). Given an SCSP problem P, consider Sol 
(P) = (def,con). An optimal solution of P is a pair (t,v) such that def{t) = v, 
and there is no t' such that v <s defft'). 

Therefore optimal solutions are solutions which have the best semiring ele- 
ment among those associated to solutions. The set of optimal solutions of an 
SCSP P will be written as Opt{P). 

Definition 8 (problem ordering and equivalence). Consider two problems 
Pi and P 2 - Then P\ Qp P 2 if Sol (Pi) Cg Sol{P 2 ). If Pi Ep P 2 and P 2 Ep Pi, 
then they have the same solution, thus we say that they are equivalent and we 
write Pi = P 2 - 



The relation Ep is a preorder. Moreover, Pi Es P 2 implies Pi Ep P 2 - Also, 
= is an equivalence relation. 

SCSP problems can be solved by extending and adapting the technique 
usually used for classical CSPs. For example, to find the best solution we could 
employ a branch-and-bound search algorithm (instead of the classical back- 
tracking), and also the successfully used propagation techniques, like arc-consis- 
tency [HI, can be generalized to be used for SCSPs. 

The detailed formal definition of propagation algorithms (sometimes called 
also local consistency algorithms) for SCSPs can be found in 0. For the purpose 
of this paper, what is important to say is that the generalization from classical 
CSPs concerns the fact that, instead of deleting values or tuples, obtaining local 
consistency in SCSPs means changing the semiring values associated to some 
tuples or domain elements. The change always brings these values towards the 
worst value of the semiring, that is, the 0. Thus, it is obvious that, given an SCSP 
problem P and the problem P' obtained by applying some local consistency 
algorithm to P, we must have P' Es P- Another important property of such 
algorithms is that Sol{P) = Sol(P'), that is, local consistency algorithms do not 
change the set of solutions. 



2.2 Abstraction 

Abstract interpretation jllblb] is a theory developed to reason about the relation 
between two different semantics (the concrete and the abstract semantics) . The 
idea of approximating program properties by evaluating a program on a simpler 
domain of descriptions of “concrete” program states goes back to the early 70’s. 
The inspiration was that of approximating properties from the exact (concrete) 
semantics into an approximate (abstract) semantics, that explicitly exhibits a 
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structure (e.g., ordering) which is somehow present in the richer concrete struc- 
ture associated to program execution. 

The guiding idea is to relate the concrete and the abstract interpretation of 
the calculus by a pair of functions, the abstraction function a and the concre- 
tization function 7 , which form a Galois connection. 

Let (C, C) (concrete domain) be the domain of the concrete semantics, while 
(-^i <) (abstract domain) be the domain of the abstract semantics. The partial 
order relations reflect an approximation relation. Since in approximation theory 
a partial order specifies the precision degree of any element in a poset, it is 
obvious to assume that if a is a mapping associating an abstract object in 
(-4, <) for any concrete element in (C C), then the following holds: if a{x) < y, 
then y is also a correct, although less precise, abstract approximation of x. The 
same argument holds if x C l{y)- Then y is also a correct approximation of x, 
although X provides more accurate information than 7 ( 1 /). This gives rise to the 
following formal definition. 

Definition 9 (Galois insertion). Let (C, C) and (.4, <) be two posets (the 
concrete and the abstract domain). A Galois connection ( 0 , 7 ) : (G, C) ^ (4., <) 
is a pair of maps a : C ^ A and 7 : 4 — 1 C such that 

1. a and 7 are monotonic, 

2. for each x € C,x Q 7 (a(x)) and 

3. for each y e 4, 0 ( 7 ( 1 /)) < y. 

Moreover, a Galois insertion (of A in C) ( 0 , 7 ) : (C,E) (-4, <) is a Galois 

connection where 7 • a = Id^- 

Property 2 is called extensivity of a • 7 . The map a ( 7 ) is called the lower 
(upper) adjoint or abstraction (concretization) in the context of abstract inter- 
pretation. 

The following basic properties are satisfied by any Galois insertion: 

1 . 7 is injective and a is surjective. 

2. a • 7 is an upper closure operator in (C, G). 

3. a is additive and 7 is co-additive. 

4. Upper and lower adjoints uniquely determine each other. Namely, 

7 = ^ ^ I E 2/}. a = n't 22 S 4 I X < 7 ( 2 /) 

c A 

5. a is an isomorphism from ( 70 ) (C) to 4, having 7 as its inverse. 

An example of a Galois insertion can be seen in Figure 0 Here, the concrete 
lattice is ([0, 1], <), and the abstract one is ({0, 1}, <). Function a maps all real 
numbers in [0,0.5] into 0, and all other integers (in (0.5, 1]) into 1. Function 7 
maps 0 into 0.5 and 1 into 1. 

One property that will be useful later relates to a precise relationship between 
the ordering in the concrete lattice and that in the abstract one. 
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Theorem 1 (total ordering). Consider a Galois insertion from (C, C) to 
(Al, <). Then, if C is a total order, also < is so. 

Proof. It easy follows from the monotonicity of a (that is, x Q y implies a{x) < 
a{y), and from its surjectivity (that is, there is no element in A which is not the 
image of some element in C via a). □ 

Usually, both the concrete and the abstract lattice have some operators that 
are used to define the corresponding semantics. Most of the times it is useful, 
and required, that the abstract operators show a certain relationship with the 
corresponding concrete ones. This relationship is called local correctness. 

Definition 10 (local correctness). Let f : ^ C he an operator over the 

concrete lattice, and assume that f is its abstract counterpart. Then f is locally 
correct w.r.t. f z/ Vxi, . . . , G C./(xi, . . . , x„) C^{f{a{xi),...,a{xn))). 

3 Abstracting Soft CSPs 

Given the notions of soft constraints and abstraction, recalled in the previous 
sections, we now want to show how to abstract soft constraint problems. The 
main idea is very simple: we just want to pass, via the abstraction, from an SCSP 
P over a certain semiring S to another SCSP P over the semiring S, where the 
lattices associated to S and S are related by a Galois insertion as shown above. 

Definition 11 (abstracting SCSPs). Consider the concrete SCSP problem 
P = {C, con) over semiring S, where 

— S = {A, +, X , 0, 1) and 

— C = {co, . . . , c„} with Ci = {coni, deff) and defi : — >■ A; 

we define the abstract SCSP problem P = {C, con) over the semiring S, 
where 
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— C = {co, • ■ ■ , Cn} with Ci = {corii, defi) and defi : — >■ A; 

— if L = {A, <) is the lattice associated to S and L = {A, <) the lattice asso- 
ciated to S, then there is a Galois insertion {a, 7) such that a : L ^ L; 

— X is locally correct with respect to x . 

Notice that the kind of abstraction we consider in this paper does not change 
the structure of the SCSP problem. That is, C and C have the same number 
of constraints, and Ci and Ci involve the same variables. The only thing that is 
changed by abstracting an SCSP is the semiring. Thus P and P have the same 
graph topology (variables and constraints), but different constraint definitions, 
since if a certain tuple of domain values in a constraint of P has semiring value a, 
then the same tuple in the same constraint of P has semiring value a{a). Notice 
also that a and 7 can be defined in several different ways, but all of them have 
to satisfy the properties of the Galois insertion, from which it derives, among 
others, that a(0) = 0 and a(l) = 1. 

Example 1. As an example, consider any SCSP over the semiring for optimiza- 
tion 

Swcsp = U {— 00 }, max, -I-, — 00 , 0) 

(where costs are represented by negative reals) and suppose we want to abstract 
it onto the semiring for fuzzy reasoning 

Spcsp = ([0, 1], max, min, 0, 1). 

In other words, instead of computing the maximum of the sum of all costs, we 
just want to compute the maximum of the minimum of all costs, and we want to 
normalize the costs over [0..1]. Notice that the abstract problem is in the FCSP 
class and it has an idempotent x operator (which is the min). This means that 
in the abstract framework we can perform local consistency over the problem 
in order to find inconsistencies. As noted above, the mapping a : {'R-~ ,<wcsp 
) — >■ ([0, 1], <FCSp) can be defined in different ways. For example one can decide 
to map all the reals below some fixed real x onto 0 and then to map the reals 
in [x,0] into the reals in [0,1] by using a normalization function, for example 

/w = 

Example 2. Another example is the abstraction from the fuzzy semiring to the 
classical one: 

Scsp = ({0, 1}, V, A, 0, 1). 

Here function a maps each element of [0, 1] into either 0 or 1. For example, one 
could map all the elements in [0, x] onto 0, and all those in (x, 1] onto 1, for some 
fixed X. Figure 13 represents this example with x = 0.5. 

We have defined Galois insertions between two lattices (L,<s) and {L,<g) 
of semiring values. However, for convenience, in the following we will often use 
Galois insertions between lattices of problems {PL, Cg) and {PL, Cg) where PL 
contains problems over the concrete semiring and PL over the abstract semiring. 
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This does not change the meaning of our abstraction, we are just upgrading the 
Galois insertion from semiring values to problems. Thus, when we will say that 
P = a{P), it will mean that P is obtained by P via the application of a to all 
the semiring values appearing in P. 

An important property of our notion of abstraction is that the composition 
of two abstractions is still an abstraction. This allows to build a complex ab- 
straction by defining several simpler abstractions to be composed. 

Theorem 2 (abstraction composition). Consider an abstraction from the 
lattice corresponding to a semiring S\ to that corresponding to a semiring S2, 
denoted by the pair (01,71). Consider now another abstraction from the lattice 
corresponding to the semiring S2 to that corresponding to a semiring S3, denoted 
by the pair (02,72). Then the pair (oi • 02,72 • 7i) is an abstraction as well. 

Proof. We first have to prove that (0,7) = (oi • 02,72 ■ 7i) satisfies the four 
properties of a Galois insertion: 

— since the composition of monotone functions is again a monotone function, 
we have that both o and 7 are monotone functions; 

— given a value x € Si, from the first abstraction we have that x Gi 71(01(0:)). 
Moreover, for any element y G S2, vie have that y O2 72(02(2/))- This holds 
also for y = Oi(x), thus by monotonicity of 71 we have a: Gi 71 (72 (02(01(0;)))). 

— a similar proof can be used for the third property; 

— the composition of two identities is still an identity . 

To prove that X3 is locally correct w.r.t. Xi, it is enough to consider the 
local correctness of X2 w.r.t. Xi and of X3 w.r.t. X2, and the monotonicity of 
7 i- 



4 Properties and Advantages of the Abstraction 

In this section we will define and prove several properties that hold on abstrac- 
tions of soft constraint problems. The main goal here is to point out some of the 
advantages that one can have in passing through the abstracted version of a soft 
constraint problem instead of solving directly the concrete version. 



4.1 Relating a Soft Constraint Problem and Its Abstract Version 

Let us consider the scheme depicted in Figure El Here and in the following 
pictures, the left box contains the lattice of concrete problems, and the right 
one the lattice of abstract problems. The partial order in each of these lattices is 
shown via dashed lines. Gonnections between the two lattices, via the abstraction 
and concretization functions, is shown via directed arrows. In the following, we 
will call S = (A, -I-, x, 0 ,l) the concrete semiring and S = (A, +, x, 0 ,l) the 
abstract one. Thus we will always consider a Galois insertion (0,7) : (A, <s) ^ 

(A, <§). 
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Fig. 3. The concrete and the abstract problem. 



In Figure E| -P is the starting SCSP problem. Then with the mapping a we 
get P = a{P), which is an abstraction of P. By applying the mapping 7 to P, 
we get the problem 'y{a{P)). Let us first notice that these two problems (P and 
7(a(P))) are related by a precise property, as stated by the following theorem. 

Theorem 3. Given an SCSP problem P over S, we have that P C5 7(a(P)). 

Proof. Immediately follows from the properties of a Galois insertion, in parti- 
cular from the fact that x <s 7(Q^(a;)) for any x in the concrete lattice. In fact, 
P Es 'y{ct:{P)) means that, for each tuple in each constraint of P, the semiring 
value associated to such a tuple in P is smaller (w.r.t. <s) than the correspon- 
ding value associated to the same tuple in 7(a(P)). □ 

Notice that this implies that, if a tuple in 7(a(P)) has semiring value 0, then 
it must have value 0 also in P. This holds also for the solutions, whose semiring 
value is obtained by combining the semiring values of several tuples. 

Corollary 1. Given an SCSP problem P over S, we have that Sol(P) 
Sol{jia{P)). 

Proof. We recall that Sol{P) is just a constraint, which is obtained as 0 (C) JJ-con- 
Thus the statement of this corollary comes from the monotonicity of x and -I-. 
□ 



Therefore, by passing from P to 7(a(P)), no new inconsistencies are introdu- 
ced: if a solution of 7(o;(P)) has value 0, then this was true also in P. However, 
it is possible that some inconsistencies are forgotten (that is, they appear to be 
consistent after the abstraction process). 

If the abstraction preserves the semiring ordering (that is, applying the ab- 
straction function and then combining gives elements which are in the same 
ordering as the elements obtained by combining only), then there is also an inte- 
resting relationship between the set of optimal solutions of P and that of a{P). 
In fact, if a certain tuple is optimal in P, then this same tuple is also optimal in 
a(P). Let us first investigate the meaning of the order-preserving property. 
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Definition 12 (order-preserving abstraction). Consider two sets Ii and I 2 
of concrete elements. Then an abstraction is said to be order-preserving if 

n n ^ n ^ n ^ 

X^I\ x£l2 x£li x£l2 

where the products refer to the multiplicative operations of the concrete (U) and 
the abstract (U) semirings. 

In words, this notion of order-preservation means that if we first abstract and 
then combine, or we combine only, we get the same ordering (but on different 
semirings) among the resulting elements. 

Example 3. An abstraction which is not order-preserving can be seen in Figure^ 
Here, the concrete and the abstract sets, as well as the additive operations of the 
two semirings, can be seen from the picture. For the multiplicative operations, 
we assume they coincide with the gib of the two semirings. 

In this case, the concrete ordering is partial, while the abstract ordering is 
total. Functions a and /3 are depicted in the figure by arrows going from the 
concrete semiring to the abstract one and vice versa. Assume that the concrete 
problem has no solution with value 1. Then all solutions with value a or 6 are 
optimal. Suppose a solution with value b is obtained by computing b = Ixb, while 
we have a = 1 x a. Then the abstract counterparts will have values a(l) x' a{b) = 
1 x' 0 = 0 and 0 ( 1 ) x' o;(a) = 1 x' 1 = 1. Therefore the solution with value a, 
which is optimal in the concrete problem, is not optimal anymore in the abstract 
problem. 




Fig. 4. An abstraction which is not order-preserving. 



Example 4- The abstraction in FigureHis order-preserving. In fact, consider two 
abstract values which are ordered, that is 0 <' 1. Then 1 = 1 x' 1 = a{x) x' a{y), 
where both x and y must be greater than 0.5. Thus their concrete combination 
(which is the min), say v, is always greater than 0.5. On the other hand, 0 can 
be obtained by combining either two O’s (therefore the images of two elements 
smaller than or equal to 0.5, whose minimum is smaller than 0.5 and thus smaller 
than v), or by combining a 0 and a 1, which are images of a value greater than 
0.5 and one smaller than 0.5. Also in this case, their combination (the min) is 
smaller than 0.5 and thus smaller than v. Thus the order-preserving property 
holds. 
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Example 5. Another abstraction which is not order-preserving is the one that 
passes from the semiring {N U {-|-oo}, min, sum, 0, -l-oo), where we minimize the 
sum of values over the naturals, to the semiring {N U {-l-oo}, min, max, 0, -l-oo), 
where we minimize the maximum of values over the naturals. In words, this 
abstraction maintains the same domain of the semiring, and the same additive 
operation (min), but it changes the multiplicative operation (which passes from 
sum to max) . Notice that the semiring orderings are the opposite as those usually 
used over the naturals: if i is smaller than j then j <$ i, thus the best element 
is 0 and the worst is -l-oo. The abstraction function a is just the identity, and 
also the concretization function 7. 

In this case, consider in the abstract semiring two values and the way they are 
obtained by combining other two values of the abstract semiring: for example, 
8 = max{7,8) and 9 = max{l,9). In the abstract ordering, 8 is higher than 9. 
Then, let us see how the images of the combined values (the same values, since a 
is the identity) relate to each other: we have sum{7, 8) = 15 and sum{l, 9) = 10, 
and 15 is lower than 10 in the concrete ordering. Thus the order-preserving 
property does not hold. 

Notice that, if we reduce the sets Ii and I 2 to singletons, say x and y, then 
the order-preserving property says that a{x) <g a{y) implies that x <s y- This 
means that if two abstract objects are ordered, then their concrete counterparts 
have to be ordered as well, and in the same way. Of course they could never be 
ordered in the opposite sense, otherwise a would not be monotonic; but they 
could be incomparable. Therefore, if we choose an abstraction where incompa- 
rable objects are mapped by a onto ordered objects, then we don’t have the 
order-preserving property. A consequence of this is that if the abstract semi- 
ring is totally ordered, and we want an order-preserving abstraction, then the 
concrete semiring must be totally ordered as well. 

On the other hand, if two abstract objects are not ordered, then the cor- 
responding concrete objects can be ordered in any sense, or they can also be 
not comparable. Notice that this restriction of the order-preserving property to 
singleton sets always holds when the concrete ordering is total. In fact, in this 
case, if two abstract elements are ordered in a certain way, then it is impossi- 
ble that the corresponding concrete elements are ordered in the opposite way, 
because, as we said above, of the monotonicity of the a function. 

Theorem 4. Consider an abstraction which is order-preserving. Given an 
SCSP problem P over S, we have that Opt{P) C Opt{a{P)). 

Proof. Let us take a tuple t which is optimal in the concrete semiring S, with 
value V. Then v has been obtained by multiplying the values of some subtuples. 
Suppose, without loss of generality, that the number of such subtuples is two 
(that is, we have two constraints): v = Vi x V 2 . Let us then take the value 
of this tuple in the abstract problem, that is, the abstract combination of the 
abstractions of v\ and V 2 ' this is v' = a{vi) x' a{v 2 ). We have to show that if v 
is optimal, then also v' is optimal. 
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Suppose then that v' is not optimal, that is, there exists another tuple t" 
with value v" such that v' <s' v" . Assume v" = v'{ x' v'^- Now let us see the 
value of tuple t" in P. If we set v" = a{vi), then we have that this value is 
V = vi X V2- Let us now compare v with v. Since v' <g v" , by order-preservation 
we get that v <s v. But this means that v is not optimal, which was our initial 
assumption. Therefore v' has to be optimal. □ 

Therefore, in case of order-preservation, the set of optimal solutions of the 
abstract problem contains all the optimal solutions of the concrete problem. In 
other words, it is not allowed that an optimal solution in the concrete domain be- 
comes non-optimal in the abstract domain. However, some non-optimal solutions 
could become optimal by becoming incomparable with the optimal solutions. 

Thus, if we want to find an optimal solution of the concrete problem, we could 
find all the optimal solutions of the abstract problem, and then use them on the 
concrete side to find an optimal solution for the concrete problem. Assuming 
that working on the abstract side is easier than on the concrete side, this method 
could help us find an optimal solution of the concrete problem by looking at just 
a subset of tuples in the concrete problem. 

Another important property, which holds for any abstraction, concerns com- 
puting bounds that approximate an optimal solution of a concrete problem. In 
fact, any optimal solution, say t, of the abstract problem, say with value v, can 
be used to obtain both an upper and a lower bound of an optimum in P. In 
fact, we can prove that there is an optimal solution in P with value between 
■j{v) and the value of t in P. Thus, if we think that approximating the optimal 
value with a value within these two bounds is satisfactory, we can take t as an 
approximation of an optimal solution of P. 

Theorem 5. Given an SCSP problem P over S, consider an optimal solution 
of a{P), say t, with semiring value v in a{P) and v in P. Then there exists an 
optimal solution t of P, say with value v, such that v <v < 7(v). 

Proof. By local correctness of the multiplicative operation of the abstract semi- 
ring, we have that v <s 7(u)- Since v is the value of t in P, either t itself is 
optimal in P, or there is another tuple which has value better than v, say v. We 
will now show that v cannot be greater than 7(0). 

In fact, assume by absurd that ^{v) <s v- Then, by local correctness of the 
multiplicative operation of the abstract semiring, we have that a(y) is smaller 
than the value of t in a{P). Also, by monotonicity of a, by 7(u) <s v we get 
that h <g a{v). Therefore by transitivity we obtain that v is smaller than the 
value of t in a{P), which is not possible because we assumed that v was optimal. 

Therefore there must be an optimal value between v and 7(u). □ 

Thus, given a tuple t with optimal value v in the abstract problem, instead 
of spending time to compute an exact optimum of P, we can do the following: 

— compute 7(h), thus obtaining an upper bound of an optimum of P; 

— compute the value of t in P, which is a lower bound of the same optimum 

of P; 
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— If we think that such bounds are close enough, we can take t as a reasonable 
approximation (to be precise, a lower bound) of an optimum of P. 

Notice that this theorem does not need the order-preserving property in the 
abstraction, thus any abstraction can exploit its result. 



4.2 Working on the Abstract Problem 

Consider now what we can do on the abstract problem, a{P). One possibility is 
to apply an abstract function /, which can be, for example, a local consistency 
algorithm or also a solution algorithm. In the following, we will consider functions 
/ which are always intensive, that is, which bring the given problem closer to the 
bottom of the lattice. In fact, our goal is to solve an SCSP, thus going higher in 
the lattice does not help in this task, since solving means combining constraints 
and thus getting lower in the lattice. Also, functions / will always be locally 
correct with respect to any function fsoi which solves the concrete problem. We 
will call such a property solution-correctness. More precisely, given a problem 
P with constraint set C, fsoi{P) is a new problem P' with the same topology 
as P whose tuples have semiring values possibly lower. Let us call C the set of 
constraints of P' . Then, for any constraint c' S C , c' — (^C) ^var(c')- In other 
words, fsoi combines all constraints of P and then projects the resulting global 
constraint over each of the original constraints. 

Definition 13. Given an SCSP problem P over S, consider a function f on 
a{P). Then f is solution- correct if given any fsoi which solves P, f is locally 
correct w.r.t. fsoi- 

We will also need the notion of safeness of a function, which just means that 
it maintains all the solutions. 

Definition 14. Given an SCSP problem P and a function f : PL — >■ PL, f is 
safe if Sol{P) = SolifiP)). 

It is easy to see that any local consistency algorithm, as defined in can 
be seen as a safe, intensive, and solution-correct function. 

From f{a{P)), applying the concretization function 7, we get 7(/(a(P))), 
which therefore is again over the concrete semiring (the same as P). The follo- 
wing property says that, under certain conditions, P and P ® 7(/(a(P))) are 
equivalent. Figure El describes such a situation. In this figure, we can see that 
several partial order lines have been drawn: 

— on the abstract side, function / takes any element closer to the bottom, 
because of its intensiveness; 

— on the concrete side, we have that 

• P® 7(/(q;(P))) is smaller than both P and 7(/(a(P))) because of the 
properties of ®; 

• 7 (/(q^(-P))) is smaller than 7(a(P)) because of the monotonicity of 7; 
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• 7 (/(q^(-P))) is higher than fsoi{P) because of the solution-correctness of 

/; 

• fsoi{P) is smaller than P because of the way fsoi{P) is constructed; 

• if X is idempotent, then it coincides with the gib, thus we have that 
P ® lif{c({P))) is higher than fsoi{P), because by definition the gib is 
the higher among all the lower bounds of P and j{f{a{P))). 




Fig. 5. The general abstraction scheme, with x idempotent. 



Theorem 6. Given an SCSP problem P over S, consider a function f on a{P) 
which is safe, solution-correct, and intensive. Then, ifx is idempotent, Sol{P) = 
Sol{P(^^{f{a{Pm. 

Proof. Take any tuple t with value v in P, which is obtained by combining 
the values of some subtuples, say two: v = vi x V2. Let us now consider the 
abstract versions of v\ and V2'. a{v\) and a{v2). Function / changes these values 
by lowering them, thus we get f{a{vi)) = v[ and f{a{v2)) = v'2. 

Since / is safe, we have that v'l x' v'2 = a{v\) x' a{v2) = v' . Moreover, 
/ is solution-correct, thus v <$ ^{v'). By monotonicity of 7, we have that 
iW) <s iWi) for * = 1 : 2 . This implies that 7(u') <s ( 7 (r’i) x 7 (i' 2 ))> since 
X is idempotent by assumption and thus it coincides with the gib. Thus we have 
that V <s (7K) X 7 (^^ 2 ))- 

To prove that P and P ® l{f{c({P))) give the same value to each tuple, we 
now have to prove that u = (ui x 7(ui)) x {v2 x 7(^2))- By commutativity of x, 
we can write this as (ui x ^2) x (7(v^) x ^{v'2)). Now, ?;i x W2 = v by assumption, 
and we have shown that v <s iWi) x 7(r’2)- Therefore v x (7(v5^) x 7(t’2)) = v. 
□ 



This theorem does not say anything about the power of /, which could make 
many modifications to a{P), or it could also not modify anything. In this last 
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case, 7(/(a(P))) = 7(a(P)) □ P (see FigureEI), so P ® 7(/(a(P))) = P, which 
means that we have not gained anything in abstracting P. However, we can 
always use the relationship between P and a(P) (see Theorem 21 and 0 to find 
an approximation of the optimal solutions and of the inconsistencies of P. 




Fig. 6. The scheme when / does not modify anything. 



If instead / modifies all semiring elements in a{P), then if the order of the 
concrete semiring is total, we have that P ® 7(/(a(P))) = 'y{f{a{P))) (see 
Figure O, and thus we can work on j{f{a{P))) to find the solutions of P. In 
fact, 7(/(a(P))) is lower than P and thus closer to the solution. 




Fig. 7. The scheme when the concrete semiring has a total order. 



Theorem 7. Given an SCSP problem P over S, consider a function f on a{P) 
which is safe, solution-correct, and intensive. Then, if x is idempotent, f modi- 
fies every semiring element in ot{P), and the order of the concrete semiring is 
total, we have that P Hg 7(/(o(P))) 3s fsoi{P)- 
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Proof. Consider any tuple t in any constraint of P, and let us call v its semiring 
value in P and Vsoi its value in fsoi(P)- Obviously, we have that Vsoi v- 
Now take v' = 'y{a{v)). By monotonicity of a, we cannot have v <s v'. Also, 
by solution-correctness of /, we cannot have v' <s Vsoi- Thus we must have 
Vsoi "£s v' <s V, which proves the statement of the theorem. □ 

Notice that we need the idempotence of the x operator for Theorem El and 
0 If instead x is not idempotent, then we can prove something weaker. Figure 
El shows this situation. With respect to Figure El we can see that the possible 
non-idempotence of x changes the partial order relationship on the concrete 
side. In particular, we don’t have the problem P®7(/(a(P))) any more, nor the 
problem fsoi{P), since these problems would not have the same solutions as P 
and thus are not interesting to us. We have instead a new problem P' , which is 
constructed in such a way to “insert” the inconsistencies of 7(/(a(P))) into P. 
P' is obviously lower than P in the concrete partial order, since it is the same 
as P with the exception of some more O’s, but the most important point is that 
it has the same solutions as P. 




Fig. 8. The scheme when x is not idempotent. 



Theorem 8. Given an SCSP problem P over S, eonsider a function f on a{P) 
which is safe, solution- correct and intensive. Then, if x is not idempotent, con- 
sider P' to be the SCSP which is the same as P except for those tuples which 
have semiring value 0 in 7(a(/(P))); these tuples are given value 0 also in P' . 
Then we have that Sol{P) = Sol(P'). 

Proof. Take any tuple t with value v in P, which is obtained by combining 
the values of some subtuples, say two: v = vi x V2. Let us now consider the 
abstract versions of v\ and V2' a(ui) and a{v2). Function / changes these values 
by lowering them, thus we get f{a{vi)) = v[ and /(a(i>2)) = 

Since / is safe, we have that v[ x' v'2 = a{vi) x' 0(^2) = v' . Moreover, / is 
solution-correct, thus v <$ jiv'). By monotonicity of 7, we have that "/{v') <5 
7(^9 for *= 1 , 2 . Thus we have that v <s 7(u') for i = 1 , 2 . 



126 



S. Bistarelli et al. 



Now suppose that 7(^1 ) = 0 . This implies that also v = 0 . Therefore, if we 
set v\ = 0, again the combination of vi and V2 will result in v, which is 0. □ 



Summarizing, the above theorems can give us several hints on how to use the 
abstraction scheme to make the solution of P easier: If x is idempotent, then 
we can replace P with P ®^{a{f{P))), and get the same solutions (by Theorem 
inj- If instead x is not idempotent, we can replace P with P' (by Theorem]^. In 
any case, the point in passing from P to P^j{a{f{P))) (or P') is that the new 
problem should be easier to solve than P, since the semiring values of its tuples 
are more explicit, that is, closer to the values of these tuples in a completely 
solved problem. 

More precisely, consider a branch-and-bound algorithm to find an optimal 
solution of P. Then, once a solution is found, its value will be used to cut away 
some branches, where the semiring value is worse than the value of the solution 
already found. Now, if the values of the tuples are worse in the new problem 
than in P, each branch will have a worse value and thus we might cut away 
more branches. For example, consider the fuzzy semiring (that is, we want to 
maximize the minimum of the values of the subtuples): if the solution already 
found has value 0.6, then each partial solution of P with value smaller than 
or equal to 0.6 can be discarded (together with all its corresponding subtree in 
the search tree), but all partial solutions with value greater than 0.6 must be 
considered; if instead we work in the new problem, the same partial solution with 
value greater than 0.6 may now have a smaller value, possibly also smaller than 
0.6, and thus can be disregarded. Therefore, the search tree of the new problem 
is smaller than that of P. 

Another point to notice is that, if using a greedy algorithm to find the initial 
solution (to use later as a lower bound), this initial phase in the new problem 
will lead to a better estimate, since the values of the tuples are worse in the new 
problem and thus close to the optimum. In the extreme case in which the change 
from P to the new problem brings the semiring values of the tuples to coincide 
with the value of their combination, it is possible to see that the initial solution 
is already the optimal one. 

Notice also that, if x is not idempotent, a tuple of P' has either the same 
value as in P, or 0 . Thus the initial estimate in P' is the same as that of P 
(since the initial solution must be a solution), but the search tree of P' is again 
smaller than that of P, since there may be partial solutions which in P have 
value different from 0 and in P' have value 0 , and thus the global inconsistency 
may be recognized earlier. 

The same reasoning used for Theorem E| on a{P) can also be applied to 
f{a{P)). In fact, since / is safe, the solutions of f{a{P)) have the same values 
as those of a{P). Thus also the optimal solution sets coincide. Therefore we have 
that Opt{f{a{P))) contains all the optimal solutions of P if the abstraction is 
order-preserving. This means that, in order to find an optimal solution of P, we 
can find all optimal solutions of /(a(P)) and then use such a set to prune the 
search for an optimal solution of P. 
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Theorem 9. Given an SCSP problem P over S, consider a function f on P 
which is safe, solution- correct and intensive, and let us assume the abstraction 
is order-preserving. Then we have that Opt{P) C Opt{f{a{P))). 

Proof. Easy follows from Theorem 2] and from the safeness of /. □ 

Theorem 0can be adapted to f{a{P)) as well, thus allowing us to use an 
optimal solution of /(a(P)) to find both a lower and an upper bound of an 
optimal solution of P. 



5 Some Abstraction Mappings 

In this section we will list some semirings and several abstractions between them, 
in order to provide the reader with a scenario of possible abstractions that he/she 
can use, starting from one of the semirings considered here. Some of these semi- 
rings and/or abstractions have been already described in the previous sections 
of the paper, however here we will re-define them to make this section self- 
contained. Of course many other semirings could be defined, but here we focus 
on the ones for which either it has been defined, or it is easy to imagine, a system 
of constraint solving. The semirings we will consider are the following ones: 

— the classical one, which describes classical CSPs via the use of logical and 
and logical or: 



Scsp = {{T,F},V,A,F,T) 

— the fuzzy semiring, where the goal is to maximize the minimum of some 
values over [0, 1]: 



Sfuzzy = {[QA], max, min, 0,1) 

— the extension of the fuzzy semiring over the naturals, where the goal is to 
maximize the minimum of some values of the naturals: 

SfuzzyN = {N U {-\-oo}, max, min, 0, -boo) 

— the extension of the fuzzy semiring over the positive reals: 

S fuzzy R = {R^ G {-\-oo}, max, min, 0, -boo) 

— the optimization semiring over the naturals, where we want to maximize the 
sum of costs (which are negative integers): 

SoptN = {Z~ U {-oo}, max, -b, -oo, 0) 

— the optimization semiring over the negative reals: 



SoptR={R U {-oo},max, -b,-oo,0) 
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— the probabilistic semiring, where we want to maximize a certain probability 
which is obtained by multiplying several individual probabilities. The idea 
here is that each tuple in each constraint has associated the probability of 
being allowed in the real problems we are modeling, and different tuples in 
different constraints have independent probabilities (so that their combined 
probability is just the multiplication of their individual probabilities) |1()|. 
The semiring is: 



Sprob — ( [^j : max, X , 0, 1) 

— the subset semiring, where the elements are all the subsets of a certain set, 
the operations are set intersection and set union, the smallest element is the 
empty set, and the largest element is the whole given set: 

5.„fc=(iP(A),U,f|,0,A). 

We will now define several abstractions between pairs of these semirings. The 
result is drawn in Figure 0 where the dashed lines denote the abstractions that 
have not been defined but can be obtained by abstraction composition. In reality, 
each line in the figure represents a whole family of abstractions, since each (a, 7) 
pair makes a specific choice which identifies a member of the family. Moreover, 
by defining one of this families of abstractions we do not want to say that there 
do not exist other abstractions between the two semirings. 

It is easy to see that some abstractions focus on the domain, by passing to 
a given domain to a smaller one, others change the semiring operations, and 
others change both: 

1. from fuzzy to classical CSPs: this abstraction changes both the domain and 
the operations. The abstraction function is defined by choosing a threshold 
within the interval [0, 1], say x, and mapping all elements in [0,a;] to F and 
all elements in (a:, 1] to T. Consequently, the concretization function maps T 
to 1 and F to x. See Figure 0as an example of such an abstraction. We recall 
that all the abstractions in this family are order-preserving, so Theorem 0 
can be used. 

2. from fuzzy over the positive reals to fuzzy CSPs: this abstraction changes 
only the domain, by mapping the whole set of positive reals into the [0, 1] 
interval. This means that the abstraction function has to set a threshold, say 
X, and map all reals above x into 1, and any other real, say r, into Then, 
the concretization function will map 1 into -l-oo, and each element of [0,1), 
say y, into y x x. It is easy to prove that all the members of this family of 
abstractions are order-preserving. 

3. from probabilistic to fuzzy CSPs: this abstraction changes only the multipli- 
cative operation of the semiring, that is, the way constraints are combined. 
In fact, instead of multiplying a set of semiring elements, in the abstracted 
version we choose the minimum value among them. Since the domain re- 
mains the same, both the abstraction and the concretization functions are 
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the identity (otherwise they would not have the properties required by a Ga- 
lois insertion, like monotonicity). Thus this family of abstractions contains 
just one member. 

It is easy to see that this abstraction is not order-preserving. In fact, consider 
for example the elements 0.6 and 0.5, obtained in the abstract domain by 
0.6 = mm(0.7, 0.6) and 0.5 = min(0.9, 0.5). These same combinations in 
the concrete domain would be 0.7 x 0.6 = 0.42 and 0.9 x 0.5 = 0.45, thus 
resulting in two elements which are in the opposite order with respect to 0.5 
and 0.6. 

4. from optimization-N to fuzzy-N CSPs: here the domain remains the same 
(the negative integers) and only the multiplicative operation is modified. 
Instead of summing the values, we want to take their minimum. As noted in 
a previous example, these abstractions are not order-preserving. 

5. from optimization-R to fuzzy-R CSPs: similar to the previous one but on 
the negative reals. 

6. from optimization-R to optimization-N CSPs: here we have to map the ne- 
gative reals into the negative integers. The operations remain the same. A 
possible example of abstraction is the one where a{x) = [a;] and ^{x) = x. 
It is not order-preserving. 

7. from fuzzy-R to fuzzy-N CSPs: again, we have to map the positive reals into 
the naturals, while maintaining the same operations. The abstraction could 
be the same as before, but in this case it is order-preserving (because of the 
use of min instead of sum) . 

8. from fuzzy-N to classical CSPs: this is similar to the abstraction from fuzzy 
CSPs to classical ones. The abstraction function has to set a threshold, say x, 
and map each natural in [0, x\ into F, and each natural above x into T. The 
concretization function maps T into -l-oo and F into x. All such abstractions 
are order-preserving. 

9. from subset CSPs to any of the other semirings: if we want to abstract to 
a semiring with domain A, we start from the semiring with domain V{A). 
The abstraction mapping takes a set of elements of A and has to choose 
one of them by using a given function, for example min or max. The con- 
cretization function will then map an element of A into the union of all the 
corresponding sets in V{A). For reason similar to those used in Example 3, 
some abstractions of this family may be not order-preserving. 



6 Related Work 

We will compare here our work to other abstraction proposals, more or less 
related to the concepts of constraints. 

Abstracting valued CSPs. The only other abstraction scheme for soft constraint 
problems we are aware of is the one in 0 , where valued CSPs m are abstracted 
in order to produce good lower bounds for the optimal solutions. The concept of 
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valued CSPs is similar to our notion of SCSPs. In fact, in valued CSPs, the goal 
is to minimize the value associated to a complete assignment. In valued CSPs, 
each constraint has one associated element, not one for each tuple of domain 
values of its variables. However, our notion of soft CSPs and that in valued 
CSPs are just different formalizations of the same idea, since one can pass from 
one formalization to the other one without changing the solutions, provided that 
the partial order is total |2|. However, our abstraction scheme is different from 
the one in Pj. In fact, we are not only interested in finding good lower bounds 
for the optimum, but also in finding the exact optimal solutions in a shorter 
time. Moreover, we don’t define ad hoc abstraction functions but we follow the 
classical abstraction scheme devised in 0, with Galois insertions to relate the 
concrete and the abstract domain, and locally correct functions on the abstract 
side. We think that this is important in that it allows to inherit many properties 
which have already been proven for the classical case. It is also worth noticing 
that our notion of an order-preserving abstraction is related to their concept of 
aggregation compatibility, although generalized to deal with partial orders. 

Abstracting classical CSPs. Other work related to abstracting constraint pro- 
blems proposed the abstraction of the domains HHI322I, or of the graph topo- 
logy (for example to model a subgraph as a single variable or constraint) 0. We 
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did not focus on these kinds of abstractions for SCSPs in this paper, but we be- 
lieve that they could be embedded into our abstraction framework: we just need 
to define the abstraction function in such a way that not only we can change the 
semiring but also any other feature of the concrete problem. The only difference 
will be that we cannot define the concrete and abstract lattices of problems by 
simply extending the lattices of the two semirings. 

A general theory of abstraction. A general theory of abstraction has been propo- 
sed in m- The purpose of this work is to define a notion of abstraction that can 
be applied to many domains: from planning to problem solving, from theorem 
proving to decision procedures. Then, several properties of this notion are consi- 
dered and studied. The abstraction notion proposed consists of just two formal 
systems Ei and S 2 with languages L\ and L 2 and an effective total function 
/ : Li — >■ L 2 , and it is written as / : Ai => 172. Much emphasis is posed in PI 
onto the study of the properties that are preserved by passing from the concrete 
to the abstract system. In particular, one property that appears to be very desi- 
rable, and present in most abstraction frameworks, is that what is a theorem in 
the concrete domain, remains a theorem in the abstract domain (called the TI 
property, for Theorem Increasing). 

It is easy to see that our definition of abstraction is an instance of this general 
notion. Then, to see whether our concept of abstraction has this property, we 
first must say what is a theorem in our context. A natural and simple notion 
of a theorem could be an SCSP which has at least one solution with a semiring 
value different from the 0 of the semiring. However, we can be more general that 
this, and say that a theorem for us is an SCSP which has a solution with value 
greater than or equal to k, where k > 0. Then we can prove our version of the 
TI property: 

Theorem 10 (our TI property). Given an SCSP P which has a solution 
with value v > k, then the SCSP cx{P) has a solution with value v' > a(k). 

Proof. Take any tuple t in P with value v > k. Assume that v = vi x V 2 . By 
abstracting, we have v' = a(v\) x' 0 (^ 2 ). By solution correctness of x', we have 
that V <s liv'). By monotonicity of a, we have that o;(z;) <S' o:{'y{v')) = v' . 
again by monotonicity of a, we have a(k) <s' thus by transitivity a{k) <s 
v'. □ 

Notice that, if we consider the boolean semiring (where a solution has either 
value true or false), this statement reduces to saying that if we have a solution 
in the concrete problem, then we also have a solution in the abstract problem, 
which is exactly what the TI property says in m- Thus our notion of abstraction, 
as defined in the previous sections, on one side can be cast within the general 
theory proposed in m, while on the other side it generalizes it to concrete and 
abstract domains which are more complex than just the boolean semiring. This 
is predictable, because, while in uni formulas can be either true (thus theorems) 
or false, here they may have any level of satisfaction which can be described by 
the given semiring. 
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Notice also that, in our definition of abstraction of an SCSP, we have chosen 
to have a Galois insertion between the two lattices {A^ <) (which corresponds to 
the concrete semiring S) and {A, <) (which corresponds to the abstract semiring 
S). This means that the ordering in the two lattices coincide with those of the 
semirings. We could have chosen differently: for example, that the ordeing of 
the lattices in the abstraction be the opposite of those of those in the semirings. 
In that case, we would not have had property TI. However, we would have the 
dual property (called TD in jlE]), which states that abstract theorems remain 
theorems in the concrete domain. It has been shown that such a property can 
be useful in some application domains, such as databases. 

7 Conclusions and Future Work 

We have proposed an abstraction scheme for abstracting soft constraint pro- 
blems, with the goal of finding an optimal solution, or a good approximation 
of it, in shorter time. The main idea is to work on the abstract version of the 
problem and then bring back some useful information to the concrete problem, 
to make it easier to solve. 

This paper is just a first step towards the use of abstraction for helping to 
find the solution of a soft constraint problem in a shorter time. More properties 
can probably be investigated and proved, and also an experimental phase is 
necessary to check the real practical value of our proposal. We plan to perform 
such a phase within the clp(fd,S) system developed at INRIA ^Ij, which 
can already solve soft constraints in the classical way (branch-and-bound plus 
propagation via partial arc-consistency) . 

Another line for future research concerns the generalization of our approach 
to include also domain and topological abstractions, as already considered for 
classical CSPs. 

Acknowledgments. This work has been partially supported by Italian 
MURST project TOSCA. 
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Abstract. Many constraint satisfaction problems can be naturally and 
efficiently modelled using non-binary constraints like the “all-different” 
and “global cardinality” constraints. Certain classes of these non-binary 
constraints are “network decomposable” as they can be represented by 
binary constraints on the same set of variables. We compare theoretically 
the levels of consistency which are achieved on non-binary constraints to 
those achieved on their binary decomposition. We present many new re- 
sults about the level of consistency achieved by the forward checking 
algorithm and its various generalizations to non-binary constraints. We 
also compare the level of consistency achieved by arc-consistency and 
its generalization to non-binary constraints, and identify special cases of 
non-binary decomposable constraints where weaker or stronger conditi- 
ons, than in the general case, hold. We also analyze the cost, in consi- 
stency checks, required to achieve certain levels of consistency. 



1 Introduction 

Constraint satisfaction problems occur in many real-life applications such as re- 
source allocation, time tabling, vehicle routing, frequency allocation, etc. Many 
constraint satisfaction problems can be naturally and efficiently modelled using 
non-binary constraints like the “all-different” and “global cardinality” con- 
straints mm- Certain classes of these non-binary constraints are “network 
decomposable” as they can be represented by binary constraints on the 

same set of variables. Throughout this paper, we will abbreviate this to decom- 
posable. For example, an all-different constraint is decomposable into a clique of 
binary not-equals constraints. As a second example, a monotonicity constraint is 
decomposable into a sequence of ordering constraints on pairs of variables. Not 
all non-binary constraints are decomposable into binary constraints on the same 
set of variables. For example, the parity constraint even(a;i -\-X2 + a^s) cannot be 
represented as a binary constraint satisfaction problem without the introduction 
of additional variables. 

In this paper, we compare theoretically the levels of consistency which are 
achieved on non-binary constraints to those achieved on their binary decompo- 
sition. We extend the results of \n\ and include material that covers several new 
topics. To be precise, we present many new results about the level of consistency 
achieved by the forward checking algorithm and its various generalizations to 
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non-binary constraints. We also compare the level of consistency achieved by 
arc-consistency and its generalization to non-binary constraints, and identify 
special cases of non-binary decomposable constraints where weaker or stronger 
conditions, than in the general case, hold. We correct an error in ini that sug- 
gested that neighborhood inverse consistency on the binary decomposition is an 
upper bound on the level of consistency achieved by generalized arc-consistency 
on decomposable non-binary constraints. We also analyze the cost, in terms of 
consistency checks, required to achieve certain levels of consistency. A few of the 
results presented here have appeared in HH but are repeated to make this paper 
a more complete survey. 

The remainder of this paper is organized as follows. In Section 2, we give 
formal background on constraint satisfaction problems and define various levels 
of consistency. In Section 3, we compare the level of consistency achieved by 
the forward checking algorithm and its generalizations on decomposable non- 
binary constraints. In Section 4, we repeat this analysis for arc-consistency and 
its generalization. In Section 5, we make an analysis of the number of consistency 
checks required to achieve certain levels of consistency. In Section 6, we discuss 
related work, and finally, in Section 7, we conclude and discuss future work. 

2 Formal Background 

A constraint satisfaction problem (Csp) is a triple (X,D,C). A is a set of va- 
riables. For each Xi € X, Di is the domain of the variable. Each /c-ary constraint 
c G C is defined over a set of variables (xi, . . . Xk) by the subset of the cartesian 
product Di X .. . Dk which are consistent values. A solution is an assignment of 
values to variables that is consistent with all constraints. Many lesser levels of 
consistency have been defined for binary constraint satisfaction problems (see 
for full references). A problem is {i, j) — consistent iff it has non-empty domains 
and any consistent instantiation of i variables can be extended to a consistent 
instantiation involving j additional variables |0|. A problem is arc- consistent 
(AC) iff it is (1, l)-consistent. A problem is path- consistent (PC) iff it is (2,1)- 
consistent. A problem is strong path- consistent iff it is (j, l)-consistent for j < 2. 
A problem is path inverse consistent (PIC) iff it is (1, 2)-consistent. A problem 
is neighbourhood inverse consistent (NIC) iff any value for a variable can be 
extended to a consistent instantiation for its immediate neighbourhood nm. A 
problem is restricted path- consistent (RPC) iff it is arc-consistent and if a va- 
riable assigned to a value is consistent with just a single value for an adjoining 
variable then for any other variable there exists a value compatible with these 
instantiations. A problem is singleton arc- consistent (SAC) iff it has non-empty 
domains and for any instantiation of a variable, the problem can be made arc- 
consistent. Many of these definitions can be extended to non-binary constraints. 
For example, a (non-binary) constraint satisfaction problem is generalized arc- 
consistent (GAC) iff for any variable in a constraint and value that it is assigned, 
there exist compatible values for all the other variables in the constraint m- 

Following jS|, we call a consistency property A stronger than B (A > B) iff 
in any problem in which A holds then B holds, and strictly stronger {A > B) iff 
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it is stronger and there is at least one problem in which B holds but A does not. 
We call a local consistency property A incomparable with B (A ^ B) iS A is not 
stronger than B nor vice versa. Finally, we call a local consistency property A 
equivalent to i? iff A implies B and vice versa. The following identities summarize 
results from 0 and elsewhere: strong PC > SAC > PIC > RPC > AC, NIC > 
PIC, NIC ~ SAC, and NIC ~ strong PC. 

Backtracking based algorithms perform depth-first search in a tree of variable 
assignments. Each node of the tree corresponds to a different set of assignments. 
Leaf nodes in a search tree are also called branches. Many algorithms enforce 
a certain level of consistency at every node in a search tree. For example, the 
forward checking algorithm (FC) maintains a restricted form of AC that ensures 
that the most recently instantiated variable and those that are uninstantiated are 
arc-consistent. If all remaining values for a variable are removed, a domain wipe- 
out occurs and the algorithm backtracks. Forward checking can be generalized to 
an algorithm for non-binary constraints (called nFCO in |2|) which makes every 
fc-ary constraint with k — 1 variables instantiated arc-consistent. No pruning is 
performed on fc-ary constraints with less than fc — 1 variables instantiated. As 
required, this reduces to forward checking algorithm, FC when applied to purely 
binary constraints. 

Alternative and stronger generalizations of forward checking to non-binary 
constraints are studied in P]. nFCl applies (one pass of) AC on each constraint 
or constraint projection involving the current variable and exactly one future 
variable (by comparison, nFCO does not use the constraint projections). nFC2 
applies (one pass of) GAC on each constraint involving the current variable 
and at least one future variable. nFC3 makes the set of constraints involving 
the current variable and at least one future variable GAC. nFC4 applies (one 
pass of) GAC on each constraint involving at least one past variable and at 
least one future variable. nFC5 makes the set of constraints involving at least 
one past variable and at least one future variable GAC. As required, all these 
generalizations reduce to FC when applied to binary constraints. 

Even higher levels of consistency can be maintained at each nodes in the 
search tree. For example, the maintaining arc-eonsistency algorithm (MAC) en- 
forces AC at each node in the search tree If enforcing AC removes all 
remaining values for a variable, a domain wipe- out occurs and the algorithm 
backtracks. For non-binary constraints, the algorithm that maintains generali- 
zed arc-consistency (MGAC) on a (non-binary) constraint satisfaction problem 
enforces GAC at each node in the search tree. When comparing the amount of 
search performed by different backtracking algorithms, we assume that we are 
looking for all solutions and there is a static variable ordering. We say that al- 
gorithm A dominates algorithm B {A > B) \i when A visits a node then B also 
visits the equivalent node in its search tree, and strictly dominates {A > B) 
if it dominates and there is one problem on which it visits strictly fewer nodes. 
Algorithm A and B are incomparable if neither A dominates B or vice versa 
(A ~ B). The following identities summarize results from P): nFC2 > nFCl > 
nFCO, nFC5 > nFC3 > nFC2, nFC5 > nFC4 > nFC2, nFC3 - nFC4. 
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3 Forward Checking on Decomposable Constraints 

We will compare the level of consistency achieved by FC (and its generalizations) 
on decomposable non-binary constraints. We repeat this analysis for AC in the 
next section. We first identify a lower bound on the performance of FC applied 
to the binary decomposition. 

Theorem 1. For a decomposable non-binary constraint satisfaction problem, 
the forward checking algorithm, FC on the binary decomposition strictly domi- 
nates the generalized forward checking algorithm, nFCO. 

Proof. Consider a node in the search tree explored by the nFCO algorithm. As- 
sume that forward checking removes the value a for some variable x. Then x 
occurs in an fc-ary constraint in which all fc — 1 other variables have been as- 
signed values. In the binary decomposition, not all arcs between x and these 
k — 1 variables can support assigning x the value of a otherwise this would be 
a consistent extension in the non-binary representation. Hence forward checking 
on at least one of these binary arcs will remove the value a. 

To show strictness, consider a ternary constraint x < y < z with x, y and 
2 ; all having the domains {1,2}. Assume a lexicographic variable ordering and 
a numerical value ordering (similar results are obtained with other variable and 
value orderings). FC first assigns 1 to x. Forward checking then reduces the 
domain of y to 2. After assigning this unit, forward checking discovers a domain 
wipeout for z. We therefore backtrack to the root of the search tree and assign 
2 to X. Forward checking then discovers a domain wipeout for y. The problem 
is therefore insoluble, and FC shows this in 2 branches. The nFCO algorithm 
takes longer to solve this problem as it must assign 2 values before the ternary 
constraint is checked. It therefore takes 4 branches to show insolubility. □ 

We can generalize the example in the last proof to show that nFCO applied to 
non-binary constraints can explore exponentially more branches than FC on the 
binary decomposition. This proof holds for a wide variety of variable orderings. 
A variable ordering which instantiates variables with unit domains before those 
without is called an unit preference ordering. 

Theorem 2. There exists a decomposable non-binary constraint satisfaction 
problem in n variables on which the forward checking algorithm, FC applied to the 
binary decomposition explores 2 branches, but the generalized forward checking 
algorithm, nFCO explores 2"“^ branches using any value ordering and any unit 
preference variable ordering. 

Proof. Consider the n-ary constraint xi < X 2 < . ■ . < Xn with each variable 
Xi having the domain {1,2}. The variable and value ordering heuristics in the 
forward checking algorithm, FC first assign a value, 1 or 2 to some variable Xi. 
The proof divides into four cases. If 1 < i < n and the value assigned to i is 1 
then forward checking discovers a domain wipeout for Xi-\. If 1 < z < n and 
the value assigned to i is 2 then forward checking discovers a domain wipeout 
for Xi+i. If z = 1 and the value assigned to z is 1 then forward checking reduces 
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X2 to an unit domain, the unit preference variable ordering assigns this variable 
next and discovers a domain wipeout for x^. In the final case, i = n and the 
value assigned to i is 2. Forward checking then reduces x„_i to an unit domain, 
the unit preference variable ordering assigns this variable next and discovers a 
domain wipeout for Xn-2- After each case, we backtrack, assign the alternative 
value to i and discover a domain wipeout. FC thus shows that the problem is 
insoluble in 2 branches. On the other hand, the nFCO algorithm takes longer 
to solve this problem as it must assign n — 1 values before the n-ary constraint 
is checked. It therefore takes 2"“^ branches to show insolubility whatever the 
variable and value ordering. □ 

We can also give a simple upper bound on the performance of FC on the 
binary decomposition. 

Theorem 3. For a decomposable non-binary constraint satisfaction problem, 
nFCl strictly dominates the forward checking algorithm, FC on the binary de- 
composition. 

Proof. Since the problem is decomposable, the constraint projections between 
the current and one future variable are a superset of the arcs that FC applied 
to the binary decomposition makes arc-consistent. Hence, if FC on the binary 
decomposition prunes a value, so will the nFCl algorithm. 

To show strictness, consider an all-different constraint on four variables each 
with the same domain of three elements. FC shows that the binary decompo- 
sition is insoluble in 6 branches whatever the variable and value ordering. By 
comparison, nFCl take just 3 branches. □ 

We can generalize the example in the last proof to show that FC on the 
binary decomposition and nFCO may explore exponentially more branches than 
algorithms nFCl-nFC5. This proof holds for any variable and value ordering 
heuristics. 

Theorem 4. There exists a decomposable non-binary constraint satisfaction 
problem in n variables on which the nFCl-nFC5 algorithms explore just n — 1 
branches, but on which the forward checking algorithm, FC applied to the binary 
decomposition takes (n— 1)! branches, and the nFCO algorithm explores (n— 1)"“^ 
branches. 

Proof. Consider an n-ary all-different constraint on the variables x\, X2, . . .Xn, 
each with the domain {1, 2, ... n — 1}. FC explores (n — 1)! branches to show 
that the problem is insoluble. The nFCO algorithm assigns n — 1 values to the 
Xi (1 < i < n) before the n-ary all-different constraint is checked. It therefore 
takes (n— 1)"“^ branches to prove that the problem is insoluble. By comparison, 
algorithms nFCl-nFC5 show that the problem is insoluble in n — 1 branches since 
as soon as the first variable is instantiated with any one of its n — 1 values, we 
enforce GAC (AC in the projections for nFCl) and discover that the current 
subproblem (the constraint projections) admit no satisfying tuples. □ 
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These results, as well as those from | 2 j, are summarized in Figure ^ 
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Fig. 1. The performance of the forward checking algorithm, FC on the binary de- 
composition of a set of decomposable non-binary constraints compared to the various 
generalizations of forward checking, nFCO to nFC5 applied to the non-binary con- 
straints. 



4 Arc-Consistency on Decomposable Constraints 

Algorithms that enforce even higher levels of consistency than forward checking 
have been shown to be highly effective at solving binary and non-binary con- 
straint satisfaction problems (see, for example, lani)- In this section, we cha- 
racterize the level of consistency achieved by (generalized) AC on decomposable 
constraints. The following theorem (from ca) puts a lower bound on the level 
of consistency achieved by GAC on decomposable constraints with respect to 
the binary decomposition. 

Theorem 5. Generalized arc- consistency on decomposable constraints is strictly 
stronger than arc- consistency on the binary decomposition. 



As we show later on in this section, this lower bound is strict since we can 
exhibit a large class of problems on which GAC is equivalent to AC on the binary 
decomposition. In we claimed that NIC (on the binary decomposition) was 
an upper bound on the level of consistency achieved by GAC on decomposable 
non-binary constraints. This was wrong as the following theorem shows (see 
Theorem 0 for one condition under which NIC becomes strictly stronger than 



Theorem 6. Generalized arc- consistency on decomposable constraints is incom- 
parable to neighbourhood inverse consistency on the binary decomposition. 

Proof. Consider a problem with three all-different constraints on {xi,X2,X3}, 
on {a;i, X3, a;4}, and on {xi, X4, X2}, in which xi has the unitary domain {1} 
and every other variable has the domain { 2 , 3 }. This problem is generalized 
arc-consistent, but enforcing neighbourhood inverse consistency shows that it is 
insoluble. 



Proof. See fZj. 



□ 



GAC). 
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Consider the following 2-colouring problem. We have 5 variables, xi to X 5 
which are arranged in a ring. Each variable has the same domain of size 2. 
Between each pair of neighbouring variables in the binary decomposition, there 
is a not-equals constraint. In the non-binary representation, we post a single 
constraint on all 5 variables. This problem is neighbourhood inverse consistent 
but enforcing GAC on the non-binary representation shows that the problem is 
insoluble. □ 

The upper bounds we can give for GAC tend to be rather weak. This is 
perhaps not surprising as we can post very large arity non-binary constraints. 
GAC may therefore achieve very high levels of consistency. The first upper bound 
we give is rather trivial. If the largest (non-binary) constraints involve k or fewer 
variables, then (1, fc — l)-consistency is strictly stronger than GAC. 

Theorem 7. For decomposable non-binary constraints of arity k or less, (1, k — 
\)~ consistency on the binary decomposition is strictly stronger than generalized 
arc-consistency on the non-binary constraints. 

Proof. Consider any variable and value assignment. (1, k — l)-consistency ensu- 
res that we can assign consistent values to the (at most) k — 1 variable’s that 
appear with this variable in any given (non-binary) constraint. Hence, this con- 
straint is generalized arc-consistent. Thus, (l,k — l)-consistency of the binary 
decomposition implies GAC of the original problem. 

To prove strictness, consider a non-binary problem in 4 variables: x\, X 2 and 
X 3 each with domains {1,2}, and X 4 with domain {2,3}. We post a ternary 
all-different constraint on X 2 , X 3 and X 4 , and not-equals constraints between 
Xi and X 2 , and Xi and x^. Now each of these constraints is generalized arc- 
consistent, so no values are removed. However enforcing (1, 2)-consistency shows 
that the problem is insoluble because of the constraints on xi, X 2 and X 3 . (In 
this example, X 4 is only there to guarantee that there is a ternary constraint in 
the problem.) □ 

A second upper bound can be given when the non-binary constraints decom- 
pose into cliques of binary constraints. For example, an all-different constraint 
decomposes into a clique of binary not-equals constraints. Under such a restric- 
tion, NIC on the binary decomposition is strictly stronger than GAC on the 
original (non-binary) problem. 

Theorem 8. If each non-binary constraint decomposes into a clique of binary 
constraints then neighbourhood inverse consistency on the binary decomposition 
is strictly stronger than generalized arc- consistency on decomposable constraints. 



Proof. Consider any variable and value assignment. NIC ensures that we can 
assign consistent values to the variable’s neighbours. However, as the decompo- 
sition is into a clique, any (non-binary) constraint including this variable has all 
its variables in the neighbourhood. Hence, the (non-binary) constraint is gene- 
ralized arc-consistent. 
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To prove strictness, consider again the problem with three all-different con- 
straints from the proof of Theorem^l This problem is generalized arc-consistent, 
but enforcing neighbourhood inverse consistency shows that it is insoluble. □ 
We had hoped to give weaker conditions under which NIC is strictly stronger 
than GAC. For example, we considered adding the binary constraints implied 
by path consistency to the binary decomposition. However, this is not enough to 
ensure that NIC implies GAC. In general, you may need any of the implied binary 
constraints. This may lead to prohibitively large neighbourhoods in the binary 
decomposition, with any variable that has a value removable by GAC connected 
to every other variable. On a minor note, this last upper bound is strict since we 
can exhibit a class of problems in which the non-binary constraints decompose 
into cliques of binary constraint and on which GAC is equivalent to NIC on the 
binary decomposition. 

GAC on decomposable constraints is incomparable to all levels of consistency 
between strong path-consistency and restricted path-consistency on the binary 
decomposition HH. 

Theorem 9. Generalized arc- consistency on decomposable constraints is incom- 
parable to strong path-consistency, to singleton arc- consistency, to path inverse 
consistency, and to restricted path- consistency on the binary decomposition. 

Proof. See ini- □ 

These results are summarized in Figure El 



strong PC 




— strictly stronger 



Fig. 2. The consistency of GAC on a set of decomposable non-binary constraints com- 
pared to varions consistency techniques stronger than or equal to AC on the binary 
decomposition. 



Not surprisingly an algorithm that maintains GAC on decomposable con- 
straints also strictly dominates the forward checking algorithm, FC applied to 
the binary decomposition (as well strictly dominating any of the generalizations 
of FC to non-binary constraints). 

Theorem 10. For a decomposable non-binary constraint satisfaction problem, 
an algorithm that maintains generalized arc- consistency strictly dominates the 
forward checking algorithm, FC on the binary decomposition, as well as strictly 
dominating any of the generalized algorithms, nFCO to nFC5. 
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Proof. Algorithms nFC2-nFC5 enforce GAG in subsets of the problem and are 
therefore dominated by an algorithm that maintains GAG in the whole problem. 
From Theorems 1 and 3 it trivially follows that such an algorithm also dominates 
FG on the binary decomposition, nFGO and nFGl. 

To show strictness we only need to give an example where maintaining GAG 
explores less branches than nFG5. Gonsider an all-different constraint on the 
variables x, y and z, each with the domain {1, 2}. Assume a lexicographic variable 
ordering and a numerical value ordering (similar results are obtained with other 
variable and value orderings). nFG5 first assigns 1 to x, and then discovers there 
are no satisfying tuples for the all-different constraint. We therefore backtrack 
to the root of the search tree and assign 2 to x. This branch ends in failure 
by a similar argument. The problem is thus insoluble and FG5 shows this in 2 
branches. All the other forward checking algorithms also explore 2 branches. By 
comparison, enforcing GAG immediately shows the problem is insoluble without 
any search. □ 

We can generalize the example in the last proof to show that FG on the binary 
decomposition can explore exponentially more branches than an algorithm that 
maintains GAG. This proof holds for any variable and value ordering heuristics. 

Theorem 11. There exists a decomposable non-binary constraint satisfaction 
problem in n variables on which the forward checking algorithm, FC applied to 
the binary decomposition explores {n— 1)! branches, whilst GAC shows that it is 
insoluble without search. 

Proof. Gonsider an n-ary all-different constraint on the variables X\, X2, • • .Xn, 
each with the domain {1,2, ...n — 1}. At each level in the search tree of the 
forward checking algorithm, one more value is removed from the domain of the 
remaining uninstantiated variables. The branching rate therefore decreases from 
n — 1 to 1. When the n — 1th variable is instantiated, the remaining variable 
suffers a domain wipeout and backtracking occurs. Forward checking therefore 
visits (n — 1)! branches before the problem is shown insoluble. By comparison, 
enforcing GAG immediately shows that the problem is insoluble. □ 



4.1 Tree Decomposable 

We next identify a class of decomposable non-binary constraints on which GAG 
meets its lower bound {viz. AG on the binary decomposition). A special case of 
decomposable constraints are “tree decomposable” constraints in which the con- 
straint graph of the binary decomposition forms a tree (or forest of independent 
trees) . For example, the non-binary constraint that a list of variables is monoto- 
nically increasing is tree decomposable into a set of binary inequality constraints. 
Such monotonicity constraints are frequently used when we model real problems 
as they can be made to break unwanted symmetries. As the next two theorems 
demonstrate, tree decomposability topologically characterizes when GAG may 
be of benefit. If the constraint graph is a tree then GAG performs no more pru- 
ning than AG on the binary decomposition. On the other hand, if the constraint 
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graph is not a tree, then GAC can be more pruningful. We first prove that GAG 
on tree decomposable constraints is no more effective than AG on the binary 
decomposition . 

Theorem 12. Generalized arc- consistency on tree decomposable constraints is 
equivalent to arc-consistency on the binary decomposition. 

Proof. (=>) Gonsider a tree decomposable problem that is generalized arc- 
consistent. Gonsider two variables, Xi and x^, and a value for x^. The proof 
divides into two cases. Either x^ and Xj are directly connected to each other in 
some tree, or they are not. If they are connected, since the problem is generalized 
arc-consistent, there is a consistent value for Xj. If they are not connected then 
any value for Xj is consistent. Thus, the tree decomposition is arc-consistent. 

(<^) Gonsider the tree decomposition of a problem that is arc-consistent. Gon- 
sider a variable, Xi and a value from its arc-consistent domain. We now show how 
to find consistent values for all the other variables. We take the parent and each 
of the children of x^. As the tree decomposition of the problem is arc-consistent, 
we can find consistent values for these variables. We repeat this process until 
we reach the root and the leaves. We now consider any uninstantiated children 
of the root. Again, as the tree decomposition of the problem is arc-consistent, 
we can find consistent values for these variables. We then consider the children 
of these variables and repeat until all variables are instantiated. Hence, there 
exists a consistent extension for the value assigned to Xi, and the problem is 
generalized arc-consistent. □ 

This result is perhaps rather unsurprising. Freuder has shown that when 
the constraint graph of a binary constraint satisfaction problem is a tree, we can 
solve problems by enforcing AG and then instantiating the variables in a suitable 
order jS| . Hence, as AG essentially determines global consistency, GAG is unable 
to achieve anything higher. In fact, even AG is too much since a restricted form 
of AG called “directional arc-consistency” is enough to ensure backtrack free 
solutions in constraint trees [Zj. What is perhaps more surprising is that tree 
decomposition precisely characterizes when GAG can do more pruning than AG 
on the binary decomposition. To be more precise, as soon as the constraint graph 
of the binary decomposition is no longer a tree (or forest of trees) but contains 
one or more cycles, there are problems on which GAG performs more pruning 
than AG on the binary decomposition. 

Theorem 13. Given a binary constraint graph which has one or more cycles, 
then there exists a non-binary problem with this decomposition on which gene- 
ralized arc- consistency is strictly stronger than arc- consistency on the binary 
decomposition. 

Proof. By TheoremEl GAG is stronger than AG on the binary decomposition. To 
show strictness, given a binary constraint graph containing one or more cycles, we 
construct a non-binary problem with this decomposition on which GAG performs 
more pruning than AG on the binary decomposition. We first find a cycle in 
the binary decomposition. We then construct a non-binary constraint on the 
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variables in this cycle. Each variable is given a domain with the same two values. 
If the cycle found is of odd length, then we construct a non-binary constraint 
that ensures that neighbouring variables in the chain take different values. If the 
cycle found is of even length, then we construct a non-binary constraint that 
ensures that neighbouring variables in the chain take different values except for 
one pair of variables which must take equal values. Enforcing GAG on this non- 
binary constraint will show that the problem is insoluble. By comparison, the 
binary decomposition is arc-consistent. □ 

In the next section, we characterize a large class of problems which are not 
tree decomposable and on which GAG is guaranteed to achieve levels of consi- 
stency much higher than AG on the binary decomposition. 

4.2 Triangle Preserving Constraints 

By imposing some slightly stronger conditions on the type of non-binary con- 
straints, we can prove that generalized AG is significantly stronger than AG 
on the binary decomposition. One such condition (first studied in [1 7] 1 is when 
the non-binary constraints contain all length 3 cycles (triangles). The intuition 
is that the constraints then capture an inherent non-binary aspect of the pro- 
blem. We say that a set of decomposable constraints is triangle preserving if all 
triangles of variables in the constraint graph of the binary decomposition occur 
together in non-binary constraints. For example, an all-different constraint is tri- 
angle preserving as it decomposes into a clique of binary not-equals constraints. 
Binary constraints can still occur in a triangle preserving set of non-binary con- 
straints, but only if they do not form part of a triangle. A triangle preserving 
set of non-binary constraints is trivially not tree decomposable. Under the re- 
striction to triangle preserving constraints, GAG is strictly stronger than path 
inverse consistency, which itself is strictly stronger than AG. 

Theorem 14. On a triangle preserving set of constraints, generalized arc- 
consistency is strictly stronger than path inverse consistency on the binary de- 
composition. 

Proof See ^2|. □ 

A corollary of this result is that GAG on a triangle preserving set of con- 
straints is strictly stronger than restricted path-consistency or AG on the binary 
decomposition. Even when restricted to triangle preserving sets of constraints, 
GAG remains incomparable to strong path-consistency, singleton AG, and neig- 
hbourhood inverse consistency. 

Theorem 15. On a triangle preserving set of constraints, generalized arc- 
consistency is incomparable to strong path-consistency, to singleton arc- 
consistency and to neighbourhood inverse consistency on the binary decompo- 
sition. 



Proof. See ca- 



□ 
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These results are summarized in Figure 0 
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Fig. 3. The consistency of GAC on a triangle preserving set of non-binary constraints 
compared to various consistency techniques stronger than or equal to AC on the binary 
decomposition. 



5 Consistency Checks 

In the previous two sections we compared the levels of consistency achieved by 
generalized algorithms on decomposable constraints to the levels achieved by FC 
and AC on the binary decomposition. We now analyze the relative numbers of 
consistency checks required to achieve these consistencies. 

5.1 Forward Checking 

FC performs 0(d) consistency checks between the currently assigned variable and 
each future variable, where d is the maximum domain size. If Ccj is the number 
of constraints between the current variable and future variables then FC performs 
0{Ccjd) consistency checks at each node. [21 gives upper bounds in the number 
of consistency checks that algorithms nFC0-nFC5 perform at each node of the 
search tree. nFCO forward checks an n — ary constraint when n — 2 variables have 
been assigned and the n — 1th variable is the current one. If Cc,i is the number 
of constraints that involve the current variable and only one future variable then 
nFCO performs at maximum 0{Cc,id) consistency checks at each node. The 
complexities of algorithms nFCl-nFC5 depend on the levels of consistency that 
they enforce, and also on the complexity of the AC algorithm they use. We should 
note that nFCl has the requirement that all the n— consistent tuples of the n—ary 
constraint have been precomputed. This, in general, adds an exponential, to the 
arity of the constraint, number of consistency checks when the constraint is not 
defined by the allowed tuples. There are cases, like the all-different constraint, 
where computing the allowed tuples can be done in polynomial time. However, 
since the number of tuples is exponential, there can be space restrictions if we 
want to explicitly store all the tuples of all-different constraints with high arity. 

The main observation regarding the complexities of the forward checking 
algorithms is that there can only be a polynomial difference in the number of 
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consistency checks performed by any two algorithms at any node. This means 
that the results of Sections 3 and 4 regarding exponential differences between 
algorithms in terms of visited nodes are also true in terms of consistency checks. 
However, the dominance results do not carry through to consistency checks. The 
following examples show that for a decomposable non-binary constraint satis- 
faction problem, FC on the binary decomposition is incomparable to algorithms 
nFCO and nFCl in terms of consistency checks. As in fPj, we count n primitive 
consistency checks to check if an n-tuple of an n— ary constraint is consistent, 
which means that 2 checks are counted for a binary constraint. 

Example 1. Consider a ternary constraint x < y < z with x having the domain 
{0, 1, 2}, y having the domain {1, 2, 3} and 2; having the domain {2, 3, 4}. Assume 
a lexicographic variable ordering and a numerical value ordering. FC on the 
binary decomposition first assigns 0 to a: and forward checks it against y. This 
takes 6 consistency checks (2 for each value of y). Then, 1 is assigned to y and 
the assignment is forward checked against z taking 6 more consistency checks. 
nFCO assigns x to 0, j/ to 1, and then forward checks taking 9 consistency checks 
(3 for each value of z), which is 3 checks less than FC. 

Now consider the same constraint with the variables having domains {0, 1}. 
FC will show insolubility in two branches, performing 12 consistency checks. 
nFCO will explore 4 branches and perform 24 consistency checks in total. 



Example 2. To prove that FC and nFCl are incomparable in terms of consistency 
checks, consider a ternary constraint Xi < X 2 < X 3 , with xi having the domain 
{0, 1,2}, X 2 having the domain {3,4,5} and X3 having the domain {6,7,8}. FC 
will take 12 consistency checks to solve the problem while nFCl will take 18 
consistency checks. 

Now consider the example in the proof of Theorem 3. FC on the binary 
decomposition takes 28 consistency checks to prove insolubility while nFCl takes 
only 18. 

We can also show that algorithms nFC2-nFC5 are incomparable in consi- 
stency checks to FC on the binary decomposition and also incomparable with 
one another using more complicated examples. 

5.2 Arc-Consistency 

For any non-binary constraint C, specified by a predicate, GAC can be esta- 
blished by the best known algorithm, GAC-schema with 0{d^) worst-case 
complexity, where d is the maximum domain size of the variables and k is the 
arity of the constraint. AC can be enforced on the binary decomposition of a 
decomposable constraint with O(ed^) optimal worst-case complexity, where e is 
the number of binary constraints that the initial constraint decomposes into. 
We can identify a cross-over point in the size, e, of the binary decomposition. 
That is, if e > d^~^ then GAC is asympotically cheaper than AC on the binary 
decomposition. In practice, e is 0{k^), and therefore, GAC is cheaper than AC, 



Decomposable Constraints 147 



in the worst case, only when the arity of the constraints and the domain size of 
the variables are small. However, for certain types of non-binary constraints, like 
the all-different constraint, there exist algorithms that achieve GAC with much 
lower cost than 0{d^). 

An all-different constraint on k variables can be decomposed into a clique 
of 0{k^) binary constraints. AC can be achieved on the decomposition of an 
all-different constraint in 0{k^(P) checks, when a generic AC algorithm is used. 
However, since we are dealing with “not equals” constraints, AC can be achieved 
with O(fc^) worst-case complexity. This is a correction on the bound for such 
constraints given in CHI and it is based on the following observations: First, for 
a network of “not equals” constraints, an AC-3 like algorithm will revise each 
edge at most once. And second, for a “not equals” constraint, AC may remove 
a value from the domain of one of the variables if and only if the other variable 
has a unary domain. As a result, AC has 0(e) worst-case complexity, which 
is O(fc^) for the decomposition of all-different constraints. This is better than 
Regin’s specialized filtering algorithm which achieves GAC on the non-binary 
representation with 0{k^cP) worst-case complexity. However, as we demonstra- 
ted in Section 4, GAC on the non-binary representation is stronger than AC on 
the decomposition. Also, experimental results presented in the following section 
strongly suggest that Regin’s algorithm is much more efficient than an AC al- 
gorithm. Finally, If we use GAC-schema to achieve GAC then the complexity 
depends on the number of allowed tuples which is 0{ ) for one constraint. 

If we compare that with the complexity of Regin’s algorithm it is obvious that 
GAC-schema is inferior. Even for ternary constraints the difference is substan- 
tial as GAC-schema would perform 0{(P) consistency checks on one constraint, 
compared to the 0{(P) checks of Regin’s algorithm. 

6 Related Work 

Montanari looked at the approximation of non-binary constraints by binary con- 
straints on the same set of variables m He constructs a “minimal network” 
of binary constraints by projecting each non-binary constraint onto the pairs of 
variables it contains. The minimal network has a set of solutions that is a su- 
perset of the set of solutions of the original non-binary constraints. It is the best 
upper bound to the set of solutions of the non-binary constraints as no other 
binary approximation has fewer solutions. The minimal network of a decompos- 
able non-binary constraint is simply the binary decomposition. 

Dechter has studied the representation of non-binary constraints by binary 
constraints with additional (hidden) variables j0| . She identifies a trade-off bet- 
ween the number of additional variables required and the size of their domains. 
In particular, any non-binary constraint can be expressed by binary constraints 
with the addition of hidden variables with three or more values. By compari- 
son, with domains of size 2, additional variables do not improve the expressive 
power. Bacchus and van Beek compared the forward checking algorithm, nFCO 
on non-binary constraints with the forward checking algorithm FC applied to 
binary encodings that introduce extra (hidden) variables Q. 
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7 Conclusions 

We have performed a detailed theoretical comparison of the effects of binary and 
non-binary constraint propagation on decomposable non-binary constraints. We 
proved that the number of nodes visited by the forward checking algorithm, 
FC applied to the binary decomposition lies between the number visited by 
the generalized forward checking algorithms, nFCl and nFCO when applied to 
the non-binary constraints (assuming equivalent variable and value ordering). 
We also proved that generalized arc-consistency on decomposable constraints 
is strictly stronger than arc-consistency on the binary decomposition. Indeed, 
under a simple restriction, it is strictly stronger than path inverse consistency 
on the binary decomposition. By generalizing the arguments of m, these re- 
sults show that a search algorithm that maintains generalized arc-consistency on 
decomposable constraints strictly dominates a search algorithm that maintains 
arc-consistency on the binary decomposition, which itself strictly dominates the 
forward checking algorithm, FC and any of its generalizations, nFCO to nFC5. 

We corrected a result of that claims that neighbourhood inverse con- 
sistency on the binary decomposition is strictly stronger than generalized arc- 
consistency. In general, neighbourhood inverse consistency on the binary de- 
composition is incomparable to generalized arc-consistency. However, we iden- 
tify a simple condition under which neighbourhood inverse consistency on the 
binary decomposition is guaranteed to be strictly stronger than generalized arc- 
consistency. We also defined a class of decomposable non-binary constraints on 
which generalized arc-consistency collapses down onto AC on the binary decom- 
position. 

What general lessons can be learnt from this study? First, the representa- 
tion of problems can have a very large impact on the efficiency of search. Our 
results show that the comparison of different representations is very complex, 
even when restricted to a limited set of consistency properties and algorithms. 
The study of different representations thus deserves further work, both theore- 
tical and practical. Second, a non-binary representation can offer considerable 
advantages over a binary representation. Decomposing non-binary constraint 
into binary constraints can significantly reduce the level of consistency achieved 
by our constraint propagation techniques. 
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Abstract. Constraint solving techniques are frequently based on con- 
straint propagation, a technique that can be seen as a specific form of 
deduction. Using constraint programming languages enhanced with con- 
straint handling rules facilities, constraint propagation can be achieved 
just by applying deduction rules to constraints. The automatic genera- 
tion of propagation rules has been recently investigated in the particular 
case of finite domains, when constraint satisfaction problems are based 
on predefined, explicitly given constraints. Due to its interest for prac- 
tical applications, several solvers have been developed during the last 
decade for integrating finite domains into (constraint) logic program- 
ming. A possible way of integration is implemented using a unification 
algorithm to compute most general solutions of constraints. In this pa- 
per, we propose a mixed approach for designing finite domain constraints 
solvers: it consists in using a solver based on unification to improve the 
generation of propagation rules. 



1 Introduction 

In declarative programming and automated deduction, constraints help control- 
ling deduction and computation. Hence, the search space can be pruned using 
constraints and related constraint solving techniques. A lot of works in con- 
straint programming are dedicated to the development of constraint solvers for 
various computation domains. Solvers are frequently based on constraint propa- 
gation 0, a technique that can be considered as a specific form of deduction. 
A general approach consists in specifying the deduction process as a set of ru- 
les mm- Recently, the idea of programming with constraints and rules has 
attracted a strong interest Some systems (such as CHRs and 

CLAIRE 1^) have already been used successfully in a number of applications. 
Thus, there is an obvious need of algorithms for generating deduction rules for 
constraints, and algorithms for applying these rules. 

From our point of view, two classes of problems should be successively ad- 
dressed in this context. First, new frameworks must be defined to integrate 
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constraints and rules. Second, existing constraint solving tools must be adapted 
and extended to fit these new frameworks. 

On the one hand, the results of K. R. Apt and E. Monfroy 0 for finite 
domains clearly belong to the first class. The authors propose a new notion of 
rule-consistency that can be expressed in terms of rules derived from the explicit 
representation of the initial constraints. This notion is compared to well-known 
local consistencies such as arc-consistency cni.A general schema for propagation 
rules over finite domains is also presented. 

On the other hand, the integration of finite domains into logic programming 
has been extensively studied m The reason is the appropriateness of this 
combination for practical applications (such as circuit verification) . These studies 
led to new constraint solving techniques such as a unification algorithm for finite 
algebras [S|. This algorithm is used in several Prolog-like systems, where this 
semantic unification dedicated to finite domains replaces the usual syntactic 
unification. Our goal is to reuse this unification algorithm for the generation of 
propagation rules. 

Hence, this paper contributes to the second class of above-mentioned pro- 
blems. We are mainly interested in the problem of recasting an already known 
constraint solver into the Constraints + Rules paradigm. We show the interest of 
using a unification algorithm for the automatic generation of propagation rules 
for finite domains. It turns out that the rules we generate are very useful for sol- 
ving constraints, reducing constraint satisfaction problems (CSP’s), and proving 
(non-)existence of solutions. 

With respect to 0, our contributions are: 

— A well-suited data-structure to represent functions and constraints. The me- 
mory management is a major problem when dealing with the combinatorial 
explosion induced by the generation of rules. Therefore, the choice of inter- 
nal data-structures is crucial in order to tackle problems of significant size. 
The one used in the unification algorithm, namely Directed Acyclic Graphs 
(DAG), is really appropriate. 

— A new form of meta-rules, including parameters, that enables us to schema- 
tize several standard rules. 

— A more deductive approach for generating rules. New rules are built from 
already computed rules, and the left-hand side of each rule is deduced from 
the right-hand side using the unification algorithm. 

We consider propagation rules as a much more elegant way than unification to 
express solutions of constraints. Therefore, this work also improves the original 
output of the unification algorithm: the most general solution built out complex 
terms is replaced by a set of readable rules. 

The structure of this paper is as follows. First, we start with some motivati- 
ons and clarifications of our work (Section |21) . In Section 0 we recall some basic 
notations and concepts about constraint solving. We then present the unifica- 
tion algorithm in finite algebras, and we briefly show how to use its output to 
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generate all the solutions of a constraint. Then (Section we focus on deter- 
ministic rules that can be easily computed using the unification algorithm. This 
leads to our notion of propagation rules. In Section 0 we propose an algorithm 
to generate propagation rules. The significance of these rules is discussed in Sec- 
tional In Section[ 7 l we generate reduction rules a la Apt & Monfroy 0 from our 
propagation rules. Section 0 compares our approach to the one of 0 . Finally, 
we conclude with some future perspectives in Section 0 



2 Motivations 

Let us motivate our approach with a simple example. Consider the relation (or 
constraint^) : 



R'{Xi,X 2 ,X 3 ) := (Xi.X 2 + Xi.X 2 = 0 A X3.X1.X2 -f X1.X2.X3 = 1 ) 

where Xi,X2, and X3 are Boolean variables, “-I-”, and are the usual 
and, or, and not Boolean operators, and A is the logical connective. This relation 
is explicitly given by the following truth table: 



i?' 




^2 


^3 


0 


0 


0 


0 


1 


0 


0 


1 


0 


0 


1 


0 


0 


0 


1 


1 


0 


1 


0 


0 


0 


1 


0 


1 


0 


1 


1 


0 


1 


1 


1 


1 



where 1 in the column of R' means that the tuple represented by the correspon- 
ding row is in the relation. Equivalently, the relation R' can be explicitly given 
by all the tuples of R': 





A 2 


^3 


0 


0 


1 


1 


1 


1 



2.1 Automatic Generation of Reduction Rules [3j 

In [3), CSP’s based on predefined, explicitly given finite constraints are studied. 
These CSP’s are solved with rules which are automatically derived from the re- 
presentation of the constraints. Two algorithms are proposed in |^: one derives a 
complete and minimal set of domain reduction rules for enforcing arc-consistency 

^ In this paper, we sometimes refer to relations and sometimes to constraints. However, 
both terminologies can be considered as equivalent and depends on the context: 
relation is the terminology used in 113 , and constraints in 0. 
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of CSP’s, whereas, the other one generates rules that enforce a weaker local con- 
sistency, i.e., rule-consistency. In the following, we focus on this last type of 
rules. 

Consider a constraint C on a finite sequence of variables X. Then, the rules 
of |Hj are of the following form: 

Xl=Vl,... ,Xs=Vs^Y 

where: Y G X, for i G [l..s], Xi G X and Y ^ Xi, and ui, . . 
of the domains of the variables Xi,. . . ,Xg,Y respectively. 

“if for i G [l..s], the domain of the variable Xi equals the 
remove the element v from the domain of Y” . 

The Rule Generation Algorithm of generates the following set of 
rules for R'{Xi, X2, X3): 

^ X3 ^ 0. 

Xi = 1 ^ A 2 yf 0. 

Xi = 0 ^ X 2 1. 

X 2 = 1 ^ Xi y^ 0. 

X 2 = 0 ^ Xi y^ 1. 

2.2 Unification in Finite Algebras m 

By using a unification algorithm in finite algebras (the Boolean algebra with two 
elements in this example), we can obtain a solved form equivalent to R': 



. ,Vs-,v are elements 
Such a rule means: 
singleton {vi} then 



R'(Xi, X2, X3) o Xi = Fi A X2 = Xi A X3 = 1 



By orienting this equivalence, we obtain the following transformation rule: 

Xi = Yi A X2 = Yi A X3 = 1 

The left-hand side is empty since no assignment of variables is needed to apply 
the rule. Note that the unification algorithm may introduce extra variables (such 
as Yi) to express the most general solution (i.e., the right-hand side). 

2.3 The Mixed Approach 

We can notice that the approach of Section ICTI generates a huge amount of rules. 
It can happen that the rules generated for a constraint are so numerous that they 
cannot be applied efficiently. 

On the other hand, the second approach may generate terms that are quite 
difficult to understand (see Section 0. Furthermore, the structure of the con- 
straint is lost when adding extra variables: enumeration of solutions implies 
labeling these extra variables. 
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Overview The main idea of this paper is to use constraint solving techniques 
of jTJI to generate more concise sets of rules. These rules are called propagation 
rules, and they are similar to rules of [5|. Intuitively, we want to make explicit 
the deduction that can be made from an assignment of variables. This deduction 
is computed by the unification algorithm exemplified above and described in 
Section 0 In our context, a propagation rule is of the form: 

— V \ , . . . , — Vg ji' Rhs 

The left-hand side is a conjunction of solved equations of the form Xk = Vk where 
Vk is either an element of D (i.e., the initial domain of Xf^), or a parameter 
representing any element of D. The right-hand side Rhs is a conjunction of 
solved equations and membership constraints Xk € Dk, where Dk is included in 
D, and not reduced to a singleton. This right-hand side Rhs is directly derived 
from the application of the unification algorithm to R' A X± = vi, . . . , Xg = Vg . 

For instance, if we consider Xi as a parameter, the unification algorithm 
gives us the following equivalence for R': 

R'{Xi,X2,X3) a Xi = xi X 2 = xi a X 3 = 1 

This way, our GenRulesFD algorithm (see Section EJ generates the following 
set of rules for the relation R' described above: 

XiGDAX2GDAX3 = 1 ( 1 ) 

Xi = xi X2 = Xi A X3 = 1 ( 2 ) 

X2 = X2 Xi = a;2 A X3 = 1 ( 3 ) 

Comparison Propagation rules are similar to rules of Pj. The most significant 
difference is the notion of parameters. They enable us to generate less rules. 
Parameters are also a way to deduce equality between variables. For example. 
Rule El above means: “Whatever the value of Xi, X 2 is equal to Xi and X 3 
is equal to 1”. We are now able to automatically deduce equalities between 
variables in conclusion of rules, e.g., using a post-process on the previous set of 
rules, we obtain a single rule: 

T X 2 = Xi A X 3 = 1 

One may argue that we could also detect equalities on the rules of P|. This 
is true on this example. However, due to the minimality property of generated 
rules, and due to the use of inequalities in the right-hand side of rules, it is 
generally rather difficult (if not impossible) to analyze the set of rules. 

3 Constraint Satisfaction Problems 

Let us first set up shortly the framework of constraint satisfaction problem sol- 
ving. Consider a sequence of m variables X = Xi , . . . , X^ with respective do- 
mains Di, . . . , Dm- The domain Dk represents the set of values the variable Xk 
can take. The sequence of variables Xi, . . . , Xm induces an ordering on variables. 
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A constraint C is a subset of the Cartesian product Di x ... x Dm- A 
constraint satisfaction problem (CSP) V is given by a sequence of variables 
X = Xi,.-- ,Xm with associated domains Di x ... x Dm, and a set C of 
constraints, each on a subsequence of X. A solution to V is an element of 
C n X . . . X Dm- 

In this paper, we consider that D\ , . . . , Dm are included in a finite domain 
D of cardinality n. Without loss of generality, these n elements are assumed to 
be totally ordered. The minimal element (respectively maximal element) of D is 
denoted by minu (respectively max^i). 

Until now, we have defined constraints as relations, and we will use indiffe- 
rently these two notions. Since we also need to express constraints intensionally 
using an algebraic structure, we consider the constraint language given by: 

— A set of constraints (the syntax). Constraints are conjunctions of atomic 
formulae of the form: X = j, X ^ j, and X € D' where j G D and D' C 
D. These first-order formulae may contain parameters that are considered 
logically as universally quantified variables. The set of (free) variables of a 
constraint C is denoted by Var{C)- 

— The interpretation V (the semantics). 2? is a finite F-algebra (i.e., F is 
assume to be finite) given by: 

• the finite domain D, 

• and for each function symbol f G F, a function (also called operator) 
/x) over D. 

An assignment a : X ^ D uniquely extends to an homomorphism a from 
the set of terms T{F, X) to V. Together with the standard interpretation of 
= and G, this homomorphism enables one to evaluate any constraint C since 
the value a{C) is either true or false. A solution of C is an assignment a 
such that the a{C) is true (we say also that a{C) holds) - The set of solutions 
of C is denoted by SoI-d{C)- 

In all examples given in the paper, D is the Boolean algebra with two ele- 
ments, where D = {0, 1}. 

Unification in Finite Algebras 

In the following, we present a unification algorithm in finite algebras. This al- 
gorithm consists in solving constraints interpreted in a finite algebra, i.e., it 
computes solved forms equivalent to the input constraints. An ubiquitous pro- 
blem with the design of constraint solving techniques is to find a compact form 
defining all the solutions of a constraint (or equivalently all the tuples of a rela- 
tion). When dealing with arbitrary domains, constraints generally have infinitely 
many solutions. When dealing with finite domains, the problem is simpler since 
a constraint admits only finitely many solutions, and we can use this finite set to 
represent all the solutions. Moreover, we can do better when the finite domain 
is embedded into a finite algebra including operators for building terms. Indeed, 
these terms can be used to define symbolic solutions of the following form: 

Xi = ti{Y) A - - - A Xm = tm{Y) 
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where are terms built over a sequence Y = of variables 

disjoint from variables X = , Xm and associated with the domain D. 

Such a symbolic solution schematizes all the solutions obtained by assigning 
variables of V with the n values of the domain D. In fact, each ti denotes a r- 
ary function fi : D’^ — >■ D. With functionally complete finite algebras, the notions 
of terms and functions coincide, i.e, each function can be denoted by a term |^. 

Example 1. The Boolean algebra B with the domain {0,1} and the operators 
true (1), false (0), not (^), or (+), and (•) is a functionally complete algebra. 

In a functionally complete finite algebra, for each non-empty m-ary relation 
R{Xi, . . . ,Xm) there exists a unique most general (symbolic) solution. We call 
it the schematization of R: 

R{Xi, ...,Xm)^Xi= B{Y) A...AXm= tm{Y) 

The number r of new variables Y is less or equal to m. It must be chosen such 
that n’’ > |i?|, where |i?| is the number of tuples in R. Since we want to minimize 
r, we choose in general r := [log„ |i?|]. 

Example 2. Consider the Boolean algebra B and the relation R{Xi, X 2 , Xf) := 
{Xi + X^ = Xz + Xi). The elements of R are: 

( 0 , 1 , 0 ), ( 0 , 1 , 1 ), ( 1 , 0 , 0 ), ( 1 , 1 , 0 ) 

We can schematize R with only two new variables Yi, I 2 with the domain (0, 1}: 

i?(Xi, X2, X3) O = Yi A X2 = n + Y1Y2 A X3 = Y{r2 

The unification algorithm in finite algebras pITTI can be used to compute the 
schematization of R. This algorithm relies mainly on the internal representation 
of functions by n-ary Directed Acyclic Graphs (DAG’s). The functions fi, ■ ■ ■ , fm 
are defined according to an arbitrary surjective mapping from D’’ to the elements 
of R. Thus, the main step of the algorithm consists in generating DAG’s or 
functions fi, . . . , fm such that: 

R{X„ ...,Xm)^X,= /i(Y) A---AXm = fm{Y) 

Then, we are faced with the difficult problem of finding m terms that denote 
functions /i,...,/m- However, provided that D is embedded into a functio- 
nally complete algebra, we can use some operators to encode the truth tables of 
/i) • ■ ■ ) /m by terms, and subsequently to represent fi,. ■ ■ , fm by terms. Let us 
illustrate this construction. Assume a function fk given by the following truth 
table where for i G [l..r], ji represents an element of D: 



Yi 




w 


fk 


miri£) 






/fc(min_D, . . . ,min£)) 


ji 




jr 


/fc(jli ■ • ■ I jr) 


max£> 




max£> 


/fc(max_D, . . . ,max£)) 
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Furthermore, let us consider a functionally complete algebra as defined in |^, 
with some unary operators Cj (for j G D) and two binary operators +, and x : 

Cj : D ^ D {Cj{j) ■= max£), Cj{i) = min^ if t yf j) 

+ : D X D ^ D (max function) 

X : D X D ^ D (min function) 

Then, there is a direct one-to-one correspondence between the truth table of fk 
and the term tk defined as follows: 

^fc(Ti , ■ • . , Tl-) := Crain D (^h) X • • • X d (hr) ^ ; min Zl) 

-!-••• 

+ C'tl(hl) X • • • X Cj^{Yr) X fk{jl, . . . ,jr) 

+ . . . 

“1“ ^max D (^l) X • • * X C^niax oi^r) ^ fk (hIcIX Z), . . . , Hiax Z?) 

It can be shown that tk represents the function fk Hg. 

Example 3 . (Example O continued) The Boolean algebra B is such a finite alge- 
bra where Ci corresponds to the identity, Cq to (not), -I- to (or), x to (and). 
In this syntax, the term associated to = Y1Y2 is tz = Co (hi) x Ci(Y2)- 
Equivalently, when we complete it, becomes: 

^3 = Co (hi) X Co(h2) X 0 
+ Co(Fi) X Cl (Fa) X 1 
+ Ci(Fi) X Co(F2) X 0 
+ Ci(Fi) X Ci(F2) X 0 

Due to the one-to-one correspondence between truth tables of functions and 
terms of the previous form, we can retrieve the truth table of f^: 



Fi 


F 2 


/s 


0 


0 


0 


0 


1 


1 


1 


0 


0 


1 


1 


0 



The additional operators -I-, x and Cj’s are only used to provide an external 
output for the internal DAG’s. Obviously, this is unsatisfactory when we want to 
ignore the semantics of the additional operators (for more details, see jtif lTl ldj ). 
Thus, we are concerned in this paper with the improvement and clarification of 
the output of the unification algorithm. To this end, we can compute functions 
fi, ■ ■ ■ , fm using rules, and the equivalence 

i?(Xi, = /i(F) A..-AXm = UiY) 

can be used to generate the relation R as follows: 

[Generate^j] i?(Xi , . . . , X^) ^ W = /i(F) A ■ ■ ■ A X^ = /™(F) 

where Y\ G D 

where Y^ G D 
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This rule, written in an ELAN-like syntax is said non- deterministic since the 
variables ... ,Yr must be instantiated by every value in D. 

4 Towards Deterministic Rules 

Dealing with non-deterministic rules is in general rather difficult, even when 
the (rule-based) underlying programming languages provide facilities (such as 
strategies) to control this non-determinism. For this reason, we discuss in this 
section how to reduce this source of non-determinism, i.e., how to get rid of new 
local variables occurring in the right-hand side of Generate^. In counterpart, 
instead of using a single generation rule, we will have to consider finitely many 
deduction rules. We call these rules propagation rules. 



4.1 Parameters 

The unification algorithm can manage with free constants P). We call them pa- 
rameters, and denote them by lower-case letters. A parameter represents symbo- 
lically any element of the domain D (i.e., it is a universally quantified variable). 
When we consider a variable as a parameter Xk (thus, we want to forbid 
the instantiation of X^), we try to compute the most general schematization of 
R{Xi, . . . ,Xm) A Xk = Xk- If this relation is non-empty, we get the following 
equivalence: 

R{^X\ , . . . , W^) A Xk — Xk X\ = f I {xk , Yi , ... , W— i) 

A . . . 

A Xk — Xk 

A ... 

A XjYi = f^(.Xk, Yi , ... , W— 1 ) 

Note the difference with the usual equivalence: 

R{Xi, ...,Xrn)^Xi = /i(W, . . . , W) A • • • A = U(Yi, ...,Yr) 



Example 4 - (Example El continued) The variable X\ can obviously be seen as a 
parameter and thus, the extra variable Yi can be replaced by the parameter X\. 
The schematization of R 



R{Xi,X 2 , A3) o Ai = Fi A A2 = Fi + F1F2 A A3 = Y1Y2 



can be replaced by 



R{Xi, A2, A3) A Ai — a;i Ai — xi A X2 — Xi -\- X1Y2 A A3 — 2:1^2 



Thus, we have eliminated one of the extra variables of the initial schematization. 
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A necessary condition for the relation R{Xi, . . . , Xm) A Xk = Xk to be non- 
empty is that Range(fk) = D, i.e., a variable can be considered as a parameter if 
it can be assigned any element of the domain. Note that when R{Xi , . . . , X^) A 
Xk = Xk is non-empty, it is the same relation as R with a better schematization. 
If it is empty, we do not consider it anymore. 

In the best case, m — I variables are parameters and the remaining variable 
is a function of these parameters. Introducing a parameter is not only helpful to 
decrease the number of extra variables, but also to create a generic equivalence: 

R{,X\ , . . . , Xjji^ A Xj^ — X\ — y*-i^(xfc,yi,..., yr—\) 

A ... 

A Xp^ — X[^ 

A ... 

A Xm = J/l , • ■ • > Ur—l) 

This equivalence subsumes the n following equivalences (for each j G D): 

R{Xi^ • • • , Xm) A Xp^ = j Xi = /i(j, yi, . . . , yr—i) 

A ... 

A Xk = j 
A ... 

A Xm = fmU^ 2/lj • ■ • I Vr—l) 

In our algorithm for generating propagation rules, we try as much as possi- 
ble to build generic deduction rules derived from generic equivalences involving 
parameters. Therefore, our aim is to maximize the number of parameters. 



4.2 Membership Constraints 

Consider the usual equivalence 

R{Xi, ...,Xm)^Xi= /i(y) A---AXm = fm{Y) 

Now, assume that we replace the schematization Xi = fi{Y)A- ■ -AXm = fm{Y) 
by the membership constraint Xi G Range(fi) A ■ ■ ■ A Xm G Range(fm) where 
ranges of functions fi,...,fm are computed from their DAG’s. This way, we 
obtain the following deduction rule: 



R{Xi^ . . . ^ Xm) Xi G Rnngei^fi) A ■ * * A Xm G Rungei^fm) 



Instead of using the usual equivalence, we could simply consider this new de- 
duction rule. Obviously, we loose the equivalence. However, the (=J>)-direction 
remains very important to determine possible values of variables, enumerate 
these values, and generate propagation rules as defined in the following. 
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4.3 Propagation Rules 

We now use the notions of the two previous sections (i.e., parameters and mem- 
bership constraints) in order to build some propagation rules. These rules provide 
a deductive approach for describing and computing tuples of a relation. The idea 
is to set some assignments of variables (the left-hand sides) in order to compute 
deductions (the right-hand sides) from these additional hypotheses. Some sim- 
ple deductions (such as = j, Xk = Xk, and Xk € Dk) can be automatically 
extracted from the schematization computed by the unification algorithm. 

Definition 1. Assume V is either a value of D or a parameter, and D' is a 
subset of D hut not a singleton. Then, a unary relation of the form X = V or 
X G D' is denoted UR{X). 

Consider a non empty relation R and its solved form 

Xi = /i(F)A---AX„ = /™(y). 

Then, we can compute UR{Xi), . . . , UR{Xm) such that 



i?(Xi, ...,Xm)^ UR{X^) A • • • A UR{Xm) 



Each UR{Xif) is obtained by a direct analysis of the DAG (computed by the 
unification algorithm) of fk'- 

— If {fk = Xk (where Xk is a parameter)) then UR{Xk) := {Xk = Xk)', 

— otherwise, if {fk = j (where j G D)) then UR{Xk) := {Xk = j)] 

— otherwise, UR{Xk) := {Xk G Range{fk))- 

UR{Xi) A • • • A UR{Xjn) is called the unary conclusion of R{Xi , . . . , A^). 
Definition 2. Consider a constraint L of the form 

L={X,,=V.,A---AX,^ = VJ 
L is a partial instantiation constraint if: 



— s < m — 1, 

— ii,. . . ,is are indices in such that ii < . . . < ig (indices are ordered), 

— and, Eij , . . . , 1^^ are either values of D or parameters. 

Consider a partial instantiation constraint L: 

— if L is empty (s = 0), then L is the true constraint denoted by T. 

— if L contains no parameter, then L is said ground. 

— given a relation R{X\, . . . ,Xm), the conclusion of L w.r.t. R (denoted by 
Concl}i{L) ) is the unary conclusion of the relation R{X\, . . . , Xm) A L. 
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A propagation rule £ for a relation R{X \, . . . , Xm) is a rule of the form 

L CoucIr^L) 

whenever R{Xi, . . . , Xm) A L is a non-empty relation. The left-hand side of £ 
is L and is denoted Lhs{£). Respectively, the right-hand side of £ is CoucIr^L), 
and is denoted Rhs{£). 

We should keep in mind that ConclR{L) is directly derived from DAG’s 
representing the symbolic solution. These DAG’s are computed by applying the 
unification algorithm to R{Xi, . . . , Xm) A L. For sake of conciseness, we say that 
ConclR{L) is computed using the unification algorithm. 

5 Generation of Propagation Rules 

We now describe an algorithm (called GenRulesFD) to generate all the propaga- 
tion rules needed to synthesize the relation R{X\, . . . , Xm). In the next section, 
we will discuss the relevance of this set of propagation rules for R{Xi, . . . , Xm). 

The GenRulesFD algorithm builds a derivation tree in which nodes are pro- 
pagation rules. 



GenRulesFD Algorithm 

Initialization The root of the derivation tree is the rule 

T ^R CondR{T) 

where ConclR{T) is computed using the unification algorithm. RulesFD(i?), the 
set of propagation rules, is initialized with {T ^r ConclR(T)}. 

Recurrence We now describe how to built the successors of a rule £ in the 
derivation tree. Assume that Lhs{£) is of the form 

X,^=Vi,A---A X,^ = 



such that s < m — 1. 

For each variable such that is < ts+i and is a membership 

constraint in Rhs{£), we generate some propagation rules according to 

1. If is strictly included in D and is not reduced to a singleton. 

Then, for each j G 

Let L := {Xi^ = Vi^ A ■ ■ ■ A Xi^ = A Xi^^^ = j) 

— Compute ConclR{L) using the unification algorithm. 

— Add the propagation rule L ^r ConclR{L) to RulesFD(i?). 
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2 . If equals D and does not depend on another parameter. 

Then: 

Let L := = Vi^ A ■ ■ ■ A Xi^ = Vi^ A Xi^^^ = where is a new 

parameter. 

~ Compute Conclfi{L) using the unification algorithm, 

— If it has a solution, 

• then, add the propagation rule L =>/{ Condn^L) to RulesFD(i?). 

• else, proceed as in 1 . by instantiating with each value in D. 

Remark 1 . When we consider an additional equation X = j with j G D to the 
left-hand side of the current propagation rule, we usually get a new schematiza- 
tion and a new unary conclusion for the next propagation rule. However, there is 
an exception if X already depends on some parameter. In that case, unification 
fails, i.e., the parameter must be replaced by values and we need to “unfold” 
the current propagation rule. Fortunately, the values for the parameter can be 
directly retrieved from the DAG built before the failure of unification. 

GenRulesFD terminates on the current propagation rule in the following two 
situations: 

— there are at least m — 1 equations in the rule. 

— each variable of a membership constraint is smaller than the last variable of 
the left-hand side. 

Since there are only finitely many variables X\, . . . , Xm and the domain D 
is finite, GenRulesFD is finitely branching. Thus, GenRulesFD terminates. 

Proposition 1. Given a relation R{Xi, . . . , Xm), the GenRulesFD algorithm 
terminates and computes in RulesFD(i?) a finite set of propagation rules. 

Example 5 . (Example 0 continued). We give below the set of propagation rules 
generated by the GenRulesFD algorithm for the relation R on the domain D = 
{ 0 , 1 }. For sake of conciseness, we do not reproduce in the right-hand side of a 
rule an equation already occurring in the left-hand side. 





T 




Xi 


e 


D A X2 


G D A A3 G D 


(0) 


Xi 


= 0 




X2 


= 


IAA3 


G D 


(1) 


Xi 


= 1 


=^R 


X2 


e 


D A X3 


= 0 


(2) 


X2 


= 0 




Ai 


= 


IAA3 


= 0 


( 3 ) 


X2 


= 1 




Ai 


G 


DA A3 


G D 


( 4 ) 


= lAXs 


= 0 




Ai 


G 


D 




( 5 ) 


= lA As 


= 1 


=>R 


Ai 


= 


0 




(6) 


^3 


= 0 




Ai 


G 


D A X2 


G D 


( 7 ) 


^3 


= 1 




Ai 


= 


0 A A2 


= 1 


(8) 
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6 Applying Propagation Rules 

In this section, we use propagation rules to solve several standard problems such 
as: existence of solutions, constraint solving, reduction of CSP’s. 

6.1 Existence of Solutions 

Consider a constraint C defined by the relation R{Xi,... ,Xm), and the set 
RulesFD of propagation rules generated by the GenRulesFD algorithm. We are 
now interested in using rules of RulesFD to determine whether a (partial) instan- 
tiation of variables is or not a solution to C, i.e., is this instantiation included 
in ii? Propagation rules are in fact considered as a kind of pre-compilation of 
the constraint C. 

Definition 3. Let S be a ground partial instantiation constraint for a relation 
R. S is said feasible for R if there exists some a € Solxi{R) such that a{S) 
holds. The assignments a € Solx>{R) such that a{S) holds are the tuples of R 
including S. 

The following proposition states that a deductive approach using the rules 
in RulesFD(i?) allows us to decide if a constraint Xi^ = ji A ■ ■ ■ A X^^ = jg 
(s < m — 1) is feasible for R. 

Proposition 2. (Existence of a solution) Consider a relation R{X\, . . . , Xm), 
and the finite set RulesFD(i?) of propagation rules generated by the GenRulesFD 
algorithm. Then, for any ground partial instantiation constraint S , the following 
property holds: 

S is not feasible for R iff, for the longer possible match of S in RulesFD(i?), 
a contradiction with its right-hand side is raised. 

Remark 2. The constraint T is always matched by S. If there is no longer match 
than T, then we have to check Condfl(T) (i.e., the right-hand side of the initial 
rule) for possible contradiction. 

Example 6. (Example 0 continued). Consider the set of rules RulesFD(i?) given 
in Example 0 Then, we can now check for instance that: 

— = 0 A X 2 = 0 is not feasible for R, because Rule (1) yields X 2 = I, and 
so there is a contradiction. 

— X 2 = 1 A X 3 = 1 is feasible for R since Rule (6) applies. X 2 = 1 A X 3 = 1 is 
only included in Xi = 0 A ^2 = 1 A X 3 = 1. 

Remark 3. Rules with a right-hand side of the form Xk S D (such as Rule (0 in 
Example^) cannot be neglected without loosing the tuple of the relation which is 
defined by the left-hand side. These rules do not reduce domains, but they check 
the validity of a partial instantiation of variables. They also assign a domain to 
variables that have no initial domain. In fact, when considering CSP’s we assume 
that each variable is associated with a domain, but when solving constraints (or 
testing existence of solutions), we do not assume pre-assigned domains. 
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6.2 Constraint Solving 

Solving constraint satisfaction problems is an interleaving process between con- 
straint propagation (in our case domain reduction) and enumeration. In the 
previous sections, we presented rule-based domain reduction. We now focus on 
enumeration (also called splitting mechanism) which consists of assigning se- 
quentially each value of its domain to a variable. 

Due to their syntax, application of propagation rules may introduce members- 
hip constraints. To transform a membership constraint, we need the following 
rewrite rule which introduces the non-determinism: 

[Split] C A Xk € Dk => C A Xk = j where j G Dk 

Proposition 3. (Computation of solutions) Consider a relation R, and the fi- 
nite set RulesFDfi?^ of propagation rules for R. For any ground partial instan- 
tiation constraint S, the following property holds: 

Computing all the normal forms of S with respect to the rules in 

RulesFD(i?) U Split 

provides all the tuples of R including S. 



Remark 4- We consider here all the rules generated by GenRulesFD. Although 
rules with a right-hand side of the form Xk G Dk do not perform reduction, we 
keep them in the set of rules. If we consider strategies for applying rules (such 
as in ELAN El), we can test existence of solutions before enumerating these 
solutions. Moreover, variables with no pre-assigned domains are given a domain 
using these rules. Consequently, these variables can also be used for enumeration. 

Let us now illustrate with examples the use of propagation rules combined 
with the Split transformation rule in order to find the tuples of R including a 
given ground partial instantiation constraint. 

Example 7. (Example 0 continued). Consider RulesFD(i?) the set of rules com- 
puted in Example 0 and the Split transformation rule. 

— Xi = 0 A X2 = 0 is not feasible for R, because Rule (1) yields X 2 = 1, and 
consequently there is a contradiction. 

— X2 = 1 A X3 = 1 is feasible for R since Rule (6) applies. X2 = 1 A A3 = 1 is 
only included in Ai = 0 A A2 = 1 A A3 = 1. 

— X 2 = 1 is feasible for R since Rule (4) applies. The normal forms are: 

1. Ai = 0 A A2 = 1 A A3 = 0, by (4, Split(A3, 0), 5, Split(Ai, 0)) 

2. Ai = 1 A A2 = 1 A A3 = 0, by (4, Split(A3,0), 5, Split(Ai,l)) 

3. Ai = 0 A A2 = 1 A A3 = 1, by (4, Split(A3, 1), 6) 
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Example 8. Consider the relation 



R'{Xi,X 2 , Xs) := {X1X2 + X 1 X 2 = 0 A X3X1X2 + X1X2X3 = 1) 
The set RulesFD(i?') contains now propagation rules with parameters: 



T =>_R' Xi G D A X2 G D A X3 = 1 
Xi = xi =>/{' X2 = xi A X3 = 1 
X2 = X2 Ail = a ;2 A Aia = 1 



(9) 

( 10 ) 

( 11 ) 



Using RulesFD(ii') and the Split rule, we can check for instance that: 

— Xi = 0 is feasible for R' since Rule m applies (with the instantiation of 
Xi by 0), and we get the unique solution Aii = 0 A X 2 = 0 A Aia = 1. 

— Similarly, Xi = 1 is feasible for R' since Rule m applies (now with the 
instantiation of xi by 1), and the unique solution is Aii = IAX2 = lAATa = 1. 

— X3 = 0 is not feasible for i?', because there is a contradiction with Rule (EJ- 

— X3 = 1 is feasible for R' since Rule o applies and no contradiction is raised. 
The normal forms are: 

1. X\ = 1 A X2 = 1 A X3 = 1 (dOlli Split(Aii, 1), (II DU with instantiation of 



2. dfi = 0 A X 2 = 0 A X 3 = 1 ((EJ, Split(Aii, 0), (ITT]ll with instantiation of 



Note that using parameters enables us to consider equality of variables in 
conclusions of rules. Rules (cni) and m can easily be combined (e.g., by a 
post-process) in order to create the following single rule: 



6.3 Reduction of CSP’s 

Propagation rules can also be used to reduce CSP’s. Moreover, when combined 
with the Split rule, propagation rules can also solve CSP’s. 

Consider a CSP V given by a set of constraints C and a set {Xi , . . . , X^} of 
variables associated with domains Di, . . . , respectively. We assume that P 
is built out of predefined, explicitly given constraints, taken from a “repository” 
CSP called BASE. Intuitively, a “repository” CSP is a kind of database of “basic” 
constraints (see |3| for a formal definition). 

The idea is to compute RulesFD(i?i) for each basic constraint Ri from the 
repository CSP BASS. The union of these sets of rules (up to renaming and per- 
mutations of variables) is computed. Then, these rules can be used to transform 
P into an equivalent but simpler@ CSP P'. 

Note that rules involving membership constraints can now be neglected. Since 
we consider CSP’s, each variable is assigned a domain. To test existence of 

^ By “simpler” we mean that some domains of variables have eventually been reduced. 



Xi by 1 ) 



xi by 0 ) 



T Xi = X 2 A X 3 = 1 
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solutions we should check application of rules of each set RulesFD(i?i) separately: 
if there exists a set RulesFD(i?i) from which no rule was applied, then the CSP 
has no solution. This requires strategies for applying rules, and thus, it may be 
simpler to directly consider enumeration. 

Example 9. Consider R and R' (respectively defined in Example 0 and Exam- 
ple El, and their respective sets of propagation rules RulesFD(i?) (see ExampleEl 
and RulesFD(i?') (see ExampleEl- Consider now the CSP V defined by the set 
of constraints 



{R{XuX2,X^),R\X[,X^,X^)}, 

and the following domains for each variable 

Xi e {0, 1}, X2 e {0, i}, X3 e {i}, x[ e {0, 1} 

We now build the global set of rules we will use to solve V. We do not need 
variable renaming or permutation for RulesFD(i?), but we need renaming va- 
riables for rules of RulesFD(i?') . We thus consider RulesFD(i?')' corresponding 
to RulesFD(i?') where Xi is renamed into X[, and X 2 into Xi: 

X[gDAXiGDAX3 = 1 (12) 

X[ = xi ^R, X3=xiAXs = l (13) 

= X2 = CC2 A X3 = 1 (14) 

We use the union of RulesFD(i?) U RulesFD(i?')' to reduce V. First Rule (0 
of RulesFD(i?) is applied, deducing that Xi = 0 and X 2 = 1. Then, Rule da 
is applied (with X 2 instantiated to 0), and we deduce the equalities X^ = 0, 
X 3 = 1. Finally, we get the solution: 

Xl = 0,^2 = 1,^3 = 1 , X (=0 

Using another strategy, we could also have applied Rule (TH^ to deduce that 
Xi = X[ and X 3 = 1, and then. Rule (0 that would have set X 2 to 0, X\ to 0, 
and consequently, to 0. 

Note that to solve CSP’s and not only to reduce them, we can use the Split 
rule defined in Section ^21 To solve V, then we could use the strategy: apply Rule 
da to deduce that X\ — then split X\ with Split(Xi, 0), and consequently 
set X[ to 0. Finally, apply Rule m to set X 2 to 1. 

7 Reduction Rules 

We can slightly modify the syntax of our propagation rules to obtain reduc- 
tion rules as defined in 0. These reduction rules lead to a new notion of local 
consistency called rule- consistency j2j. Note that the notion of rule-consistency 
is weaker than arc-consistency (see 0), and thus, are of great interest when 
enforcing arc-consistency becomes too costly. 
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Let us now transform our propagation rules into reduction rules. Instead of 
assigning a value (or a part of a domain) to a variable in the right-hand side of 
a rule, a reduction rule removes a value from a domain of a variable. We also 
have to consider “ground partial instantiations” in order to match our notion of 
parameters to reduction rules. 

Here is the definition of reduction rule in our framework: 

Definition 4 (Reduction rule p]). Consider a constraint R on a sequence 
of variables X, a ground partial instantiation constraint L, a variable Xk G 
X\Var(L), and an element d G D. A reduction rule is of the form 

L —>■ Xk ^ d. 

Consider the reduction rule L — >■ Xk ^ d. Then: 

— L — >■ Xk ^ d is feasible (for R) if L is feasible (for R). 

— L — >■ Xk ^ d is valid (for R) if for all a G Solx>{R), ot{Xk) ^ d if a{L) 
holds. 

Let L' be a partial instantiation constraint such that L' is a strict sub-formula of 
L. Then, we say that L extends L' . Similarly, we say that the rule L — >■ Xk ^ d 
extends L' ^ Xk ^ d. 

A rule is minimal if it is feasible and it does not extend any valid rule. 

We now propose an algorithm for generating reduction rules from propagation 
rules. Rules with parameters must be duplicated into several rules in order to 
“expand” the parameters into each value of the domain. Rules with a conclusion 
of the form Xi G D A ... A Xm G D will vanish since they are not useful for 
domain reduction. 

Consider a relation R, and the set RulesFD(i?) of propagation rules computed 
with the GenRulesFD algorithm. Then, the GenGRulesFD algorithm computes in 
GRulesFD(R) the set of ground rules obtained by instantiating (in all possible 
ways) parameters occurring in rules of RulesFD(i?). 

GenGRulesFD algorithm 

GRulesFD(R) := 0 
for each ^ G RulesFD(i?) 

G' := {£} 

for each Xk = Xk in Lhs{£) 

G” := 0 

for each d G D 

for each £' G G' 

G' := G" 

GRulesFD(R) := GRulesFD(i?) U G' 
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Example 10. (Example 0 continued). The set GRulesFD(i?') for X 2 , X 3 ), 

consists of the following ground rules: 

T e H A X 2 G £> A X 3 = 1 

= 0 X 2 = 0 A X 3 = 1 

= 1 X 2 = 1 A X 3 = 1 

X 2 = 0 = 0 A X 3 = 1 

X 2 = 1 = 1 A X 3 = 1 



We need to define the notion of values of variable in a rule. This notion will 
simplify the reduction rule generation algorithm. 

Definition 5. Let i he a propagation rule for a relation R(Xi, . . . ,Xm). The 
values of the variable Xk in £, denoted by Vali{Xk) , is defined as follows: 

1. Vali{Xk) := D if Xk = Xk occurs in Rhs{i), where Xk is parameter; 

2. Vali{Xk) := {j} if Xk = j occurs in Rhs{i), where j G D; 

3. Vali(Xk) := Dk if Xk G Dk occurs in Rhs{£). 

We are now ready to present the Reduction Rules Generation algorithm. 
Its principle is quite simple: for any rule i G GRulesFD(i?), and any variable 
y occurring in the right-hand side of £ (but not in the left-hand side), we can 
conclude that y ^ d for any d which is not a value of y in £. 

Reduction Rules Generation algorithm 

RedRulesFD(i?) := 0 
for each £ G GRulesFD(i?) 

for each y G Var{Rh.s{£)) \ V ar{Lhs{£)) 
for each d £ D \ Valt{y) 

RedRulesFD(i?) := {Lhs{£) ~^y^d}\J RedRulesFD(i?) 

In order to characterize the set of rules computed with the Reduction Rules 
Generation algorithm, we need the notion of redundant rule. 

Definition 6 . Consider a relation R{X\, . . . ,Xm). Let L' and L he two ground 
partial instantiation constraints such that L' is feasible. Assume that L extends 
L' and any variable in Var(L) \ Var(L') is greater than the greatest variable 
in L' . Let L" be the unique ground partial instantiation constraint such that 
L = L' A L" . L is redundant with L' (for R) if for all a G Solx>{R), a{L”) 
holds if a{L') holds. A rule L -A Xk ^ d is redundant with L' -A Xk ^ d if L is 
redundant with L' and L' -A Xk ^ d is valid (for R). 

Remark 5. If L is redundant with L' , and L' is feasible, then, L is feasible too. 



Proposition 4. A redundant rule is not minimal. 
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Proof. If a rule L — >■ Xk ^ d is redundant, then L is feasible and there exists L' 
such that: L extends L' and L' — >■ Xk d is valid (for R). 

According to 0, one can note that we can get rid of non- minimal rules. 

We now characterize the result of the Reduction Rules Generation algo- 
rithm. 

Proposition 5. Consider a constraint R, and the set GRulesFD(i?) of ground 
rules for R. Then, the Reduction Rules Generation algorithm computes in 
RedRulesFD(i?) the set of all non-redundant feasible and valid (reduction) rules 
for R. 

Proof. By construction, left-hand sides of rules generated by GenRulesFD are all 
feasible partial instantiation constraints (for R), except redundant ones. Indeed, 
in the case of a redundant partial instantiation constraint L = L' A L”, L” 
occurs in the unary conclusion of L' , and the variables in L" are not chosen to 
extend L' . Therefore, L cannot be generated by GenRulesFD. Moreover, since 
the unary conclusion permits to retrieve all the values that can be excluded for 
each variable, the generated reduction rules are all non-redundant feasible and 
valid rules. 

Example 11. (Example continued) . We give below the set RedRulesFD(i?) of 
reduction rules for the relation R. 

= 0 ^ ^2 yf 0 
= 1 ^ X3 yf 1 
X 2 = 0 ^ yf 0 
X2 = 0 ^ X3 y^ 1 
X2 = lAX3 = l^ Xi^l 
X3 = 1 ^ 1 

X3 = 1 ^ X2 y^ 0 

Example 12. (Example E3 continued). We give below the set RedRulesFD(i?') of 
reduction rules for the relation R' {Xi,X 2 ,X^). 





T^^3 




0 


(15) 


Xi -- 


= 0^X2 




1 


( 16 ) 


Xi -- 


= 0^X3 




0 


( 17 ) 


Xi -- 


= 1 ^^2 




0 


( 18 ) 


Xi -- 


= 1 ^^3 




0 


( 19 ) 


X2-- 


= Q^Xi 




1 


(20) 


X2-- 


= 0^X3 




0 


(21) 


X2-- 


= 1 ^ 




0 


(22) 


X2-- 


= 1 ^^3 




0 


(23) 
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Note that this set of rule is not minimal. For instance, Rule (C3 is an instance 
of Rule fll 5ll . We could introduce the minimality property of 0 in order to obtain 
the minimal set of rules of 0 (this set is given in Section 0. 

8 Related Work 

Our notion of propagation rules is slightly different from the notion of reduc- 
tion rules of 0. Syntactically, our propagation rules may involve parameters 
and memberships constraints. Using parameters, a set of reduction rules can be 
represented by a single propagation rule (see Section 0 . They are useful also for 
deducing equalities between variables. Another difference is the eventual presence 
of membership constraints in the right-hand sides of rules. These membership 
constraints enable us to consider several standard problems such as reduction of 
CSP’s ^Section |ti.dl) . existence of solutions i Section Id. ID . and constraint solving 
1 Section Hi. 211 . 

In Section 0 we propose an algorithm which computes reduction rules from 
propagation rules. Compared to the initial Rules Generation algorithm of 0, 
this algorithm produces directly rules which are both feasible and valid: we do 
not need to check whether a partial instantiation constraint is feasible or not. 
Although we do not generate redundant rules (which are obviously non- minimal) , 
generated rules are not necessarily minimal. A post-process could check the 
minimality property 0 of rules. However, this would be much more costly than 
in 0 where the algorithm incrementally builds sets of minimal rules. 

Since the reduction rules we generate are identical to the rules generated 
in 0 , we enforce the same local consistency, i.e., rule-consistency. 

9 Conclusion and Future Works 

The rule-based approach described in this paper improves the output of the uni- 
fication algorithm developed in mi. Solutions of constraints are now expressed 
with a set of readable propagation rules instead of a most general solution built 
out complex terms. 

We have made very promising experiments by generating propagation rules 
with the assistance of the unification algorithm. The unary conclusions are dedu- 
ced by hand using a direct analysis of schematizations. Until now, the unification 
algorithm is a black-box, but we plan to modify it for the need of the GenRulesFD 
procedure. For this purpose, incrementality should be considered more carefully. 
Moreover, as already mentioned in the paper, the unification algorithm makes 
an heavy use of DAG’s, built with respect to the ordering assumed on varia- 
bles. Given a function, two different orderings on variables may lead to different 
DAG’s with quite different sizes. We need to study the impact of the variable 
ordering on the quality of generated propagation rules. 

We have also used our propagation rules to generate rules for reducing Con- 
straints Satisfaction Problems, as defined in 0. The reduction rules we derive 
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from our propagation rules enforce the same local consistency as the rules of |3 ■ 
However, some of our reduction rules are not minimal. Moreover, we believe that 
performing an additional costly minimization process would be rather inefficient. 
The problem of computing a minimal (in the sense of |5j) set of rules remains 
open in our framework. We believe that a specific form of minimality (e.g., ba- 
sed on the ordering on variables) could be integrated rather easily. However, it 
would be a notion weaker than in |^, and the choice of the variable ordering 
could have again an impact in the size of the generated set of rules. 

In this paper, we focused on the translation from propagation rules into rules 
of 0. Propagation rules could also perform reduction of CSP’s. However, the 
way to apply them efficiently still needs to be clarified. The next step is to extend 
our approach to deal with “inclusion propagation rules”, i.e., rules related to the 
inclusion rules of 0. 

Acknowledgments. We are grateful to K. R. Apt and the reviewers for helpful 
comments on a previous version of this paper. 
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Abstract. The search space of constraint satisfaction problems (CSPs) 
can be reduced by using value interchangeability. This notion consists of 
aggregating subsets of values that behave similarly on the future branches 
of the search. BT-CPR [8], is a typical backtracking algorithm using 
value interchangeability. It uses the Cartesian product representation of 
the search space (CPR) which aggregates partial solutions and proves 
particularly useful for finding and representing all solutions of a CSP. 

It is assessed that maintaining arc-consistency (MAC) is the most effi- 
cient general algorithm for solving hard problems. A few work on com- 
bining MAC with CPR exists. In this paper we study comparatively two 
other possible alternatives of MAC-CPR. 



1 Introduction 

A lot of real world problems can be cast as Constraint Satisfaction Problems 
(CSP). A CSP, (V,C,D), is classically defined as a set V of variables X\,X2, ■■■, x^, 
taking their values respectively in a set D of domains Di, D2, ■■■, Dn and con- 
strained by a set of constraints C = (Ci, ..., Cm}- If a constraint Cj links the 
variables xi-^jXi^, ■■■,Xi^^ then it is defined as a subset of the Cartesian product 
Di^ X Di^ X ... X Di^.. gives the arity of the constraint Ci. Two variables are 
neighbors if there is a constraint linking them. A tuple t satisfies a constraint 
Ci if the projection of t on the variables linked by Ci belongs to Ci. A tuple 
with values for all variables in P is a solution for (V,C,D) if it satisfies all the 
constraints in C. 

Depending on the original problem we may need one, several, or all possible 
solutions. The task of extracting such solutions is NP-complete in general. An 
intuitive way around this complexity barrier is to structure the search space so 
that the exploration algorithm operates on aggregated subsets of data rather 
than on individual possible instantiations. This is the idea behind the Cartesian 
product representation (CPR) which aggregates partial solutions during back- 
tracking. The use of CPR was shown to bring improvements, especially to the 
problem of finding all solutions. 

MAC is one of the most powerful general search algorithms. It consists of in- 
terleaving backtracking with a notion of local consistency called Arc Consistency 
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(AC) . In [7] is presented an algorithm called backtracking'^^ that combines MAC 
with CPR. In that case the aggregations were computed statically prior to search 
and without guarantees of maximality. In this paper we study two variants of 
MAC-CPR that incorporate the dynamical computation of maximal aggregati- 
ons. 

The rest of the paper is structured as follows. We first recall the necessary 
background. Then we present the existing work on backtracking using CPR, 
as well as the two alternatives of MAC-CPR we study. The two variants are 
compared both theoretically and experimentally. In Section 5 we discuss our 
results and suggest a possible improvement of backtracking‘s^ . 

2 Background 

The search algorithms for CSPs are generally classified either as intelligent 
backtrackers that learn from the past, or lookahead techniques that use local 
consistency in order to reduce the number of future alternatives. Typical in- 
telligent backtrackers are the Constraint-Based Back-jumping (CBJ), the Back- 
Marking [9], the Dynamic Backtracking [6] and the Partial Order Dynamic Back- 
tracking [3]. 

The most popular lookahead strategies are Forward Checking (FC) and Main- 
taining Arc-Consistency (MAC) [11]. The latter has proven to outperform most 
existing search algorithms in practice. Once a value has been instantiated, FC 
prunes from the domains of its uninstantiated neighbors (future variables) the 
values that are inconsistent with the value chosen for the current variable. MAC 
enforces a form a local consistency called Arc Consistency on all the future 
variables. 



Arc Consistency 

AC has been the subject of intensive prospection. Several versions were develo- 
ped, each of which stresses a particular property. Some AC algorithms deal with 
special cases (e.g. AC'^^ [7]). The ones that are useful for the general case are 
named ACa; where x stands for a number. ACS is often the best in computatio- 
nal time. AC7 [1] seems to be the best in the number of constraint checks while 
AC6 provides a good compromise with ACS. AC7 uses the bidirectionality of the 
constraints in order to reduce the number of checks and its enforcement within 
MAC is presented as promising. 

CPR 

Interchangeability [5] provides a principled approach to simplifying the search 
space. Values are interchangeable if exchanging one for one another in any so- 
lution produces another solution. BT-CPR [8] is one of the first search algo- 
rithms using interchangeabilities. It uses a limited form of interchangeability 
called neighborhood interchangeability (NI) to aggregate partial solutions in the 
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search space. A combination of CPR with FC (FC-CPR) was also described 
in [8]. Two values, a and 6 of a variable Xi in the CSP (V,C,D) are neighborhood 
interchangeable iff for any constraint Ci G C linking Xi and xi^, the two sets 
of values from xi^ that satisfy Ci with a, respectively with b are identical. Two 
values a and b are partially neighborhood interchangeable (PNI) against a set of 
constraints S' C C iff they are neighborhood interchangeable in the CSP (V,S,D). 
We will also say that two values a and b are partially neighborhood interchange- 
able against a set of variables C P iff they are neighborhood interchangeable 
in the CSP (N,C’,D) where C is the subset of C linking only variables from N . 

FC-CPR maintains at each node a partial solution represented as a Cartesian 
product. For example, a partial solution involving variables a and b will be re- 
presented by a Cartesian product like {A := {1, 2}) x {B := {3, 5, 8}). The values 
of the future variables that are compatible with the current partial solution are 
also structured as Cartesian products. FC-CPR prunes (FC) the domains of the 
future variables for each possible value of the current one. Based on the obtained 
active domains for the future variables, it builds a structure called the discri- 
mination tree (DT) [5] that enables a cheap merging of the result into maximal 
Cartesian products. These Cartesian products correspond to partial neighbor- 
hood interchangeable sets of the current variable against all future variables. The 
children nodes in the search tree are obtained by expanding the current partial 
solution with any of the obtained interchangeable sets. 

We recall that the DT is a tree structure having the values in some of the 
nodes. The insertion of a new value is performed by following a path from the root 
of the tree, where each node corresponds to the next feasible tuple containing 
the value, in the ordered relations of the current variable. If the corresponding 
node did not previously exist, a new branch (set) is created. The value is placed 
in the set found in the node at the end of this path. The enumeration of the 
feasible tuples is not an overhead if it can be reused in the search process, for 
example when all solutions are looked for. 



Backtracking'^^ 

In [7], a possible extension from FC to MAC-CPR was mentioned where the 
interchangeabilities were used not only for inferring partial solutions, but also 
to infer information during the propagation of arc consistency. For doing so, a 
specialized version of AC, called AC^^, was introduced. However, the algorithm 
proposed uses only static neighborhood interchangeabilities detected before the 
search starts. The interchangeabilities that appear dynamically, because of pru- 
ning, were disregarded. In that version, the further computation of fully dynamic 
interchangeabilities can be expensive since AC'^^ needs them for all variables. 

In the backtracking‘s^ of [7], the partial neighborhood interchangeability sets 
between each pair of variables are precomputed statically before search. At each 
step of the search process, the neighborhood interchangeabilities between the 
current variable and the future ones are obtained by intersecting the precompu- 
ted sets. Note that the precomputed sets are no longer maximal in general. This 




176 



M.-C. Silaghi, D. Sam-Haroud, and B. Fallings 






Fig. 1. a) FC-CPR: Full FC is performed on all future variables for all values in xo 
in order to compute a DT. b) MAC-CPR: Full FC performed on all future variables 
for all values in xq to build a DT, then AC is enforced on all future variables for the 
chosen PNI set. 



is because of the pruning induced on the future variables by the current instan- 
tiations. This pruning is obtained either by forward checking or Arc Consistency. 
No attempt of further merging is performed on the result, which means that the 
aggregations obtained are not minimal in number. A weakness of backtracking‘s^ 
is the fact that it computes several times the same intersections between inter- 
changeable sets. We will show that these operations can be avoided. 

In FC-CPR [8] the partial neighborhood interchangeabilities are computed in 
a fully dynamic way. The possible aggregations for each node (current variable) 
are computed from scratch on the basis of the previous instantiations. FC-CPR 
does not incorporate any form of AC. 

A variant of FC-CPR is proposed in [10]. It allows for cheaply getting certain 
additional solutions once the first one has been obtained. However that algorithm 
is not optimal when we need an arbitrary number of additional solutions. The 
original FC-CPR offers a more general alternative in that case. 

In [4] it was shown that the partial interchangeable sets against subsets of 
the future variables can be organized in a hierarchy of a tree. This proves helpful 
in one of the algorithms we present later. 

3 MAC and CPR 

We now present two other possible ways of interleaving backtracking on CPR 
with arc-consistency. Their main characteristics are that they: 

— compute the Cartesian products in a fully dynamic way, 

— guarantee that the Cartesian products obtained at each step are minimal in 
number 

Figures 1 and 2, illustrate the main differences between the two studied variants. 

3.1 MAC-CPR 

It is obvious that the enhancement of FC-CPR with AC should not be done by 
using AC to prune the future variables for each value of the current variable. The 
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Fig. 2. QMAC-CPR: FC is performed for all values in xo considering only one of the 
future neighbor variables (here xi) to build a DT, then AC is enforced for the chosen 
PNI set on all current and future variables (less the constraints already scanned in 
order to build the DTs). These two steps are iterated considering one by one, all the 
future neighbor variables. 



propagations performed by AC will be identical for all the members of a partially 
neighborhood interchangeable set, and the work would just be replicated. The 
simplest way to accomplish the task is therefore to enforce AC at each node, i.e. 
for each interchangeable set computed. The interchangeable sets are computed 
dynamically as in FC-CPR. MAC-CPR is obtained by simply performing an 
AC propagation for each node of FC-CPR before forward check and merging. 
Once the interchangeable values are obtained, the Arc-Consistent domains of 
the future variables with any value of an interchangeable set, are consistent with 
all the other values of that set. 

Here we have to specify that during MAC, each time that AC is reinforced 
there exists an ordering of the AC queue such that a prefix of the process is 
identical to FC. What we do in MAC-CPR is to first perform separately this 
prefix for all values, detecting sets of PNI values. We then perform the rest of 
the AC with any chosen queue ordering only once for a PNI set. 

It is worth mentioning that it may be useful to merge the next levels of 
nodes immediately after AC is applied to all of them since the pruning can 
reveal stronger interchangeabilities. 

3.2 QMAC-CPR 

In this version our goal is still to compute maximal neighborhood interchange- 
able sets at each node in order to optimize the aggregations. We have however 
observed that performing a full forward checking on all future variables at each 
node, as in MAC-CPR, is not necessarily the best choice. If we only look for the 
first solution, a lot of useless work will be done at each node for pruning irrele- 
vant parts of the search tree (i.e. for all the values of the current variable that will 
never be chosen) . Performing a full FC may also entangle eventual benefits from 
early reductions, via Arc-Consistency, of the domains of the future variables. 
Such propagation can indeed reach domain wipe-outs or detect inconsistencies 
before the whole FC is done. A similar argument is presented in [1] where it is 
argued that AC can be improved by performing the propagation immediately 
after a value is deleted. This was presented as an AC queue ordering heuristic. 
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procedure Solve ('cttrr CP, varCrt, varFut, currFD) 
if (varFut==nil) then 

if (existsNextVar(varCrt)) then 
v=getN ext Var (varCrt ) 

1.1 add(currCP,domain(v)) 
newFD=project (currFD, v) 
solve(currCP,v,getFirstFutVar(v),newFD) 

else 

ReportSolution(currCP) 

end 

return 

end 

1.2 dt=DT(varCrt, varFut, currFD) 
while (!empty(dt)) do 

1.3 dts=next(dt) 

1.4 newCP=intersectCP(currCP, dts, varCrt) 
if (modifies(dts,currCP, currFD)) then 

1.5 newFD=propagate(currFD, dts, varFut) 
if empty (newFD) then 

continue 

end 

else 

newFD=currFD 

end 

1.6 if (existFutureVariable(varCrt, varFut)) then 

newFutureVar=getNextFut Var (varCrt, varFut) 

1.7 solve(newCP, varCrt, newFutureVar,newFD) 
else 

v=getN ext Var (varCrt) 

1.8 add(newCP,domain(v)) 
newFD=project(newFD,v) 
solve(newCP,v,getFirstFutVar(v),newFD) 

end 

end 

end. 

Algorithm 1: QMAC-CPR 



In the new algorithm we propose, we have come up with a compromise that 
fulfills the criteria of: building stronger aggregations at each step, early pro- 
pagating AC and FC deletions and avoiding useless FC checks on postponed 
branches. 

The idea is to enforce AC on the future variables immediately after the do- 
main of any single future variable is pruned. This is done after the corresponding 
partial interchangeable sets Rj is built (i.e. the one concerning only the current 
variable i and the pruned future variable j). AC is maintained after any such set 
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lij € ^ij is chosen (figure 2). The early propagation of deletions obtained that 
way can also prune values from other future variables that are neighbors with 
the current variable. When this occurs, an additional gain, proportional with 
the domain size is obtained. In effect, no value in the current interchangeable 
set will have to be checked against the pruned value. 

Moreover, the cost of finding the first solution may decrease. Performing FC 
on the other future variables for the values in partial interchangeable sets 
that are different from the one actually chosen is postponed until a backtracking 
occurs, with no additional cost. The gain may not appear if the difference in 
merging throws us on a worse branch first. 

The corresponding technique is described in the algorithm 1. The function 
Solve will recursively search the solution. The parameter currCP represents the 
Cartesian product of the current labels of the instantiated variables. varCrt is 
the current variable. The currently active values in its domain are in currCP as 
well. The parameter varFut points to the neighbor future variable to be analyzed 
in this iteration, if any. If there is no neighbor future variable to analyze, then 
varFut is nil. currFD is the Cartesian product of the currently active values in 
the domains of the future variables. At the beginning, AC is initialized (we have 
used AC6 and AC7) and the obtained AC domain for the variable i is noted 
getFirstFutVar(v) returns the first future neighbor variable of v if any exists, 
otherwise nil. Then Solve is called with Solve{DQ,0, getFirstFutVar{0), Di x 
... X D^). dt represents a discrimination tree computed with the function DTQ at 
line 1.2. The algorithm used is the same with the one in [7]. The iterator next{dt) 
returns a structure containing a pair of consistent interchangeable sets in varCrt 
and varFut. inter sectCP {currCP, dts, varCrt) computes the Cartesian product 
obtained from the partial solution received in currCP when the domain of the 
current variable varCrt in dts is intersected with the one in currCP. 

At each node of the search, we first compute (line 1.2) the partial neighbor- 
hood interchangeable sets. The stuctures of AC6, respectively AC7 are used to 
improve the computation of the discrimination tree. The vectors last are used 
in order to avoid checking tuples already tested during the propagation of AC. 
Afterwards, we iterate for each set (line 1.3) the actualization of the new current 
partial solution (line 1.4) and that of the future active domains (line 1.5). The 
propagation of the pruning of the future domains is done using AC. It occurs if 
any domain was changed. If one more future neighbor variable exists (line 1.6), 
we create for it a child node in the search tree at line 1.7. Otherwise, we choose 
a new variable from the future ones and we add its domain to the Cartesian 
product of the actual partial solution (line 1.8), before the corresponding child 
node is built. 

As desired, at line 1.5 we propagate the Arc-Consistency earlier than if it is 
done after forward checking all the future variables. That would be required in 
order to built the discrimination trees for the partial neighborhood interchan- 
geability against all future variables at once. However, the result was shown 
in [4] to be identical, since the hierarchy of partial interchangeabilities is a tree. 
Moreover, the computation of the interchangeable sets is performed in a more 
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depth-first fashion than in [8]. Therefore, if we would not propagate AC, but 
just perform FC, we already obtain a version of FC-CPR that is improved for 
finding the first solution. 

A drawback of the previously presented algorithm may be that the stack with 
the structures needed by AC increases in size for graphs of constraints of high 
density, especially if versions of AC requiring many structures are used (ACT, 
AC6) . However, since many of the nodes show to not change the domains of the 
variables, the corresponding stack do not need to be used for those nodes. Most 
often, only the first variables from a set of future neighbors change the domains, 
therefore we could say that we perform AC after the first rather than after the 
last of the future neighbor variables was used for partitioning. In practice it 
happened sometimes that we needed similar AC structures on the stack with 
QMAC-CPR as with MAC-CPR, even if the technique was included in MAC- 
CPR as well. However, if one decides not to use the ACT queue heuristic of [1], 
than he can implement the propagation as described in the section 5.1. 

4 Comparing QMAC-CPR and MAC-CPR 

In this section we will show that QMAC-CPR is theoretically better that MAC- 
CPR in term of power of aggregation. While MAC-CPR guarantees maximal 
partial neighborhood interchangeable sets, QMAC-CPR produces maximal ag- 
gregations based on a more global form of interchangeability. As the experiments 
will show, this does not mean that in practice, the difference of efficiency is sig- 
nificant. To give an intuition of the theoretical superiority of QMAC-CPR, we 
start by presenting an illustrative example. We will then give a theoretical proof 
before presenting a preliminary experimental evaluation. 



4.1 Illustrative Example 

In figure 3 we present an example where QMAC-CPR gives a better aggregation 
that MAC-CPR. In the figure is presented the status when the Xk is the current 
variable. In the domain of Xk we have the active values Wfc, and Vk^i^^y 

The active values for Xk+i are , V(k+i)j and for Xk+ 2 , V(k+ 2 )i and 

W(fc+ 2 )(i+i)- The arrows show values that are eliminated when the value at the 
starting point of the vectors are chosen for the corresponding variable. We see 
that the current problem is AC. In the next description, due to space, we will 
disregard the branches where the value is chosen alone for the instantiation 

of the variable Xk- We refer to the pairs (currCP,currFD) as pairs of Cartesian 
products. 

In the presented situation, MAC-CPR will first create the pairs of Cartesian 
products 



}) ^ {'^(k+2)iT'V{k+2)y+l)})j 

{{Vki},{v(k+1)^} X {W(fc+2)J), 
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Fig. 3. Snapshot at current variable Xk- 



({^fc(i+i) }; {'*^(fc+l)j } ^ {^(fc+2)i ; ^(fc+2)(i+l)}); 

and only after the third pair is chosen and AC is enforced, will it become 
({'i'fe(i+i) }) {'^'(fe+i)^ } ^ {■y(fc+2)i})- But in that moment the branch induced by 
the second pair will already have been solved, the solution lost, and there is no 
mean to infer the solution of this new branch. 

When faced with the same situation, QMAC-CPR will first consider the Xk+i 
as future variable. In that step it obtains the pairs of Cartesian products 

({^’fe(i-l)}>{'^(fe+l)0-l)>^(fc+l),} ^ {v{k+2)i,V(k+2)(i+l)}], 

+ X {v(^k+2)i,V(k+2)^i+l)})- 

We consider now the moment when the branch for the second pair is chosen. 
The MAC that is performed at this moment will prune the value 
from Xk+2- Therefore, at the next step, the new Cartesian product pair found 
will be: 

({Vfe,,Vfc(,+i)},{V(fe+lb} X {^’(fc+2)J)- 

This pair aggregates the second and the third branch of the algorithm MAC- 
CPR. 

4.2 Theoretical Results 

Theorem 1. Any two values that are aggregated at a step of MAC-CPR will 
also be aggregated (or both rejected) during the corresponding set of steps of 
QMAC-CPR. 

Proof. Two values Vk^ and Vkj of variable Xk are aggregated by MAC-CPR 
only if they are neighborhood interchangeable with all the future variables given 
their currently active domains. We will note the future neighbor variables of the 
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variable Xk with {xfcojXfcj, With QMAC-CPR, when the first future 

neighbor variable Xk^ is considered, the two values Vki and Vk^ will also be 
aggregated because they needed to be neighborhood interchangeable with Xk„ in 
order to be aggregated by MAC-CPR. 

By induction after the order of the considered future neighbor variable, if 
the values Vki and Vkj were aggregated when the variable Xk^ considered, then 
we show that they will be also aggregated when the variable Xki^i is considered 
as future neighbor of variable Xk- Indeed, both of them will behave identically 
against all the values that were active in the domain of variable Xki^^ before Xk^ 
was considered with Xk, from hypothesis. During all the process since that mo- 
ment, the values of the domain of variable Xki^^ may have been only deactivated. 
Therefore the behavior of Vk^ and Vkj against the values still active in could 
have remained only identical and the two values will be again aggregated. Of 
course, if all the supports in Xk^^^ were already deactivated for the two variables, 
then both of them will be simultaneously rejected. n 

Corollary 1. With QMAC-CPR we obtain at least the same aggregations obtai- 
ned with MAC-CPR. Any distinct Cartesian product obtained with MAC-CPR 
will be found with QMAC-CPR, eventually merged with other Cartesian products. 

The eventual additional aggregations were illustrated in figure 3. Of course, 
if we would decide to first perform at each MAC-CPR node the AC enforcement 
for all pairs of Cartesian products, and then to try again to merge the partitions, 
all these before any child node is visited, even stronger aggregations might be 
obtained. However, that may give much overhead for finding the first solution. 
This alternative is subject to further research. 

4.3 Experiments 

The most usual ways of measuring the efficiency of an algorithm searching for 
solutions in CSPs are by counting the number of constraint checks and by measu- 
ring the time needed for solving sets of real problems. The first measure is based 
on the consideration that the time needed for maintaining the data structures is 
more or less fixed while the time needed for checking constraints is the one that 
should be taken into account if such checks, with a complexity dependent on 
the problem, become expensive. That is the case if checking a constraint reduces 
to solving a problem or handling a device. If the cost of a constraint check is 
low, then the other costs will prevail and the time measurement gives the most 
important information. However, the time measurement is implementation and 
platform dependent. 

A third way of measuring the efficiency of a backtracking, counts the number 
of expanded nodes in the search tree, the tree that would represent the states of 
the run. Even if intuitively correct, such measurements will be in certain cases 
cheated by algorithms that cluster several nodes into one, without reducing the 
overall cost. It is seldom that the work done at one node with different algorithms 
is identical. 
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Table 1. QMAC-CPR vs. MAC-CPR 



variables 


QChecks / Checks 


First Solution 


DT 


20 


611/624 


115/116 


738/762 


30 


508/523 


211/215 


764/791 


40 


847/851 


524/543 


119/123 


50 


120/122 


720/790 


107/121 


60 


120/123 


335/354 


202/209 


70 


397/410 


139/151 


571/574 


80 


183/185 


167/179 


144/147 



Even if the number of expanded nodes in the QMAC-CPR algorithm is clearly 
higher than the one of MAC-CPR, the cost of each node is expected to be at 
least proportionally lower. 

We perform our tests on binary constraints. The experiments were performed 
in a Unix environment under usual load. Therefore the comparison of running 
time is not relevant. We will however give an idea of time results. We have chosen 
to measure the performance in term of the number of checks. 

We have implemented FC-CPR and MAC-CPR where we maintain AC at 
each step using AC6 and ACT. 

As suggested before, the difference between MAC-CPR and the algorithm de- 
scribed in [7] is that MAC-CPR computes the interchangeabilities dynamically, 
but it does not use the statically computed ones during AC or for the discrimina- 
tion tree. We have also implemented the QMAC-CPR algorithm using AC6 and 
ACT. We have generated random problems with 20 to 80 variables. Each variable 
participates to 3 binary constraints in average. Each variable had a domain of 
size 8 and each constraint a tightness of 35. Those parameters were chosen to 
generate the problems close to the peak of difficulty. 

In table 1 we present the results obtained by comparing the algorithms on 50 
examples of each type. The second column presents the ratio between the number 
of constraint checks needed to find all solutions with QMAC-CPR respectively 
with MAC-CPR. The third column presents the same ratio when only the first 
solution was looked for. 

The structure of QMAC-CPR reduces also the number of comparisons needed 
in order to built the discrimination trees during the search for all solutions. The 
ratio of their number for QMAC-CPR and MAC-CPR was given in the fourth 
column and suggests a very small improvement that would be brought to FC- 
CPR in the search for all solutions. We have also verified that both versions 
of MAC-CPR bring strong improvements compared with FC-CPR. This is very 
clear in the corresponding tests, but it does not make the subject of this paper. 
Preliminary comparisons of the two new algorithms versus MAC6 and MAC7 
were also performed for 800 random problems with 40 variables, density of 30% 
and 8 values per domain. The improvements for either finding all solutions or 
for finding that no solution exists was of up to 20% in average for both time and 
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Fig. 4. The average number of constraint checks for MAC7 and MAC-CPR. The num- 
ber of checks for finding only the first solution is shown with dashed lines. 



number of constraints checks, as shown in figure 4. The first solution for loosely 
constraint problems continues to be found quicker with MAC. 

The number of the Cartesian products used to represent all solutions was 
sometimes different for the two algorithms. This was due to the additional in- 
terchangeabilities that appear by maintaining AC after each future variable is 
pruned. The QMAC-CPR may need less Cartesian products than MAC-CPR 
as it succeeds to merge some of them. The inverse is never possible. However, 
the averaged reduction has reveled to be seldom above one percent. Concerning 
the time comparisons, we mention that the ratio of the averaged observed time 
oscillated of a few percents around 1. Certain single cases were at maximum one 
order of magnitude better in time with one algorithm than with the other. 

5 Discussions 

We have presented and evaluated two possible variants of backtracking on CPR 
using AC. MAC-CPR is a straightforward extension. QMAC-CPR is more ela- 
borated and exhibit better features in theory. The empirical evaluation shows 
almost similar performances on random problems. The empirical comparison 
against MAC7 shows some advantage of the new algorithms for over-constrained 
problems. 

CPR infers from the partial solution obtained for one value, partial results 
for other values of the same variable. From this point of view, CPR belongs to 
the class of intelligent backtrackers. Several researchers have tried to combine 
lookahead strategies with some learning techniques. While CBJ [9] brings some 
improvements to FC, it seems to alter MAC [2]. The explanation can be that 
CBJ brings pruning at an average cost superior to the average efficiency of 
MAC. But CPR offers high gains at low cost and therefore, integrating it with 
lookahead strategies like MAC can be more successful than it was for the other 
learning techniques. 
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Note also that a version of FC-CPR improved for finding the first solution is 
obtained by eliminating the AC propagations from QMAC-CPR. 

5.1 EMAC-CPR 



procedure SoWe(currCP,varCrt, varFut, currFD) 
if (varFut==nil) then 

if (existsNextVar(varCrt)) then 
v=getN ext Var (varCrt ) 

2.1 add(currCP,domain(v)) 
newFD=project (currFD, v) 
solve(currCP,v,getFirstFutVar(v),newFD) 

else 

ReportSolution(currCP) 

end 

return 

end 

dt=DT=’"'‘“"“‘*(varCrt, varFut, currFD) 
while (!empty(dt)) do 
dts=next(dt) 

2.2 newCP=intersectCP(currCP,dts,varCrt) 

2.3 newFD=getFD(currFD,dts, varFut) 

if (existFutureVariable(varCrt, varFut)) then 

solve(newCP,varCrt,getNextFutVar(varCrt),newFD) 

else 

2.4 if (changesToDomainsO) then 

if (empty (newFD)) then 
I continue 

end 

end 

v=getN ext Var (varCrt ) 
add(newCP,domain(v) ) 
newFD=project (currFD ,v) 
solve(newCP,v,getFirstFutVar(v),newFD) 

end 

end 

end. 

Algorithm 2: EMAC-CPR 

We present a possible improvement of backtracking'^^ that incorporates fea- 
tures of QMAC-CPR. This algorithm has not been implemented. 

We note with K the number of future neighbors of the current variable and 
with d the maximum size of a currently active domain. As previously mentioned, 
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the algorithm presented in [7] can be enhanced by using the structure of the new 
algorithm QMAC-CPR. Indeed, even if AC is maintained only after pruning 
all the future neighbors of the current variable, that could be done with the 
procedure described in algorithm Extended MAC-CPR (EMAC-CPR) presented 
in algorithm 2. Doing like QMAC-CPR, the cost of computing the intersection 
of the partial interchangeable sets is reduced from the combinatorial worst case 
when all tuples of sets from all partial interchangeable sets are considered, Kn^ , 
to by maintaining on the stack the partial intersection of several such sets. 
In the presented algorithm, we propose to try to merge the statically computed 
partially interchangeable sets. That can be accomplished using a discrimination 
tree algorithm (j)j;enhanced-^ representative value of each of the 

precomputed sets. 

The algorithm Dj;enhanced jg same as the one described in [5] with the 
only difference that the substitutability that was obtained statically, like in [7], is 
recursively used to obtain a dynamically computed one, as previously mentioned. 
It is obvious that if two values belonging to two different neighborhood inter- 
changeable sets can be merged (are interchangeable), than the two sets can be 
merged. getFD will prune from the active domain of the future variable implied 
in dts the values deactivated in dts. The changes to domains are recorded whene- 
ver done (at lines 2. 2, 2. 3) and they can launch an AC maintenance (at line 2.4). 
The other functions of EMAC-CPR are the same with those in QMAC-CPR. 

6 Conclusion 

Two variants of MAC with CPR, called MAC-CPR and QMAC-CPR, were deve- 
loped and presented in this paper. The corresponding advantages and drawbacks 
as well as their sources were discussed. QMAC is theoretically better but shows 
no significant gains on random problems. The result of the theoretical analysis 
remains interesting. 

QMAC can be seen simultaneously as both primal and dual space oriented. 
Indeed, the search is performed variable after variable, and in the same time 
it is performed constraint after constraint. For example, in the case of binary 
constraints, considering a pair of variables as QMAC-CPR does with the current 
and a future neighbor variable, reduces to considering the constraint linking 
them. This can help in the understanding of the two streams of approaches. By 
studying it, further algorithms could be transferred in an improved way from 
one of them to the other one. An example of such an application is suggested in 
section 5.1. 
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Abstract. This paper presents a system for solving mixed infinite and finite 
domains linear problem using a Constraint Logic Programming (CLP) 
Environment. The contributions of our system are introduced in two directions. 
Firstly, unlike existing systems, the splitting of a variable’s domain is based on 
the right hand side value of the first constraint in which it is involved rather 
than the splitting over an arbitrary value. Also, the splitting process is 
automatically performed by the system, when needed, rather than being the 
user’s responsibility. Secondly, a relatively transparent integration is met 
between two Constraint Logic Programming solvers. The former is a Partial 
Look Ahead solver over rationals as well as integers with the support of the 
aforementioned domain splitting mechanism, while the latter is a Simplex-Like 
solver named CLP(Q). Each counterpart submits some services to the other in 
order that the coherent system improves the search efficiency and tackles their 
individual main defects. 

Keywords: Constraint Logic Programming, Interval Reasoning, Domain 
Splitting, Simplex-Like Solver. 



1 . Introduction 

A mixed infinite and finite domains problem (MIFDP) can be defined as a search 
problem [ 18 ] in which it is required to solve the following linear model: 

, ajXjjOP) bi for i-l.m, j-l.n (1) 

loj < Xj < up j (2) 

X j , loj, upi , Cl j , b i G R 

Where m is the number of constraints, n is the number of X variables, Op e {=, <, 
<, >, >,5^1, R is the set of real numbers, any constraint of type (l)is named multi- 
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variable constraint, and any constraint of type (2) is named unary- variable constraint. If 
lOj = - 00 , upj =00 then Xj is named simple variable otherwise it is a restricted 
variable. If \/Xj : Z e Xj and loj , upj are integer numbers then the problem is 
named a Linear Constraint Satisfaction Problem (LCSPf, where Z is the set of 
integers. If Xj , loj , upj g R, and Z ^ Xj : 3 Xj then the problem is named an 
Interval Linear Constraint Satisfaction Problem (ILCSP). 

The aim is to reach one of the following states: 

1 .No feasible solution to the given model, i.e. the model is inconsistent. 

2. One or more solution is feasible, and one or more of them, if needed, is optimum 
solution(s) according to the specific user criterion, which aims to either minimizes the 
cost or maximizes the profit. At this case, the system is consistent. 

An incremental decision procedure (search algorithm), that is utilized to solve a 
MIFDP problem, is defined as one that uses a constraint whenever it arrives to the 
system to decide its consistency with the currently remaining system constraints 
without searching from scratch. Embedding such procedure(s) in a Logic 
Programming (LP) Language motivated the creation of Constraint Logic 
Programming (CLP) languages. To improve the abstraction of the modeling stage as 
well as the efficiency of the search stage, CLP approaches [6, 15] inherit the 
declarativity and the backtracking from LP and modify other features, namely, 
unification, constraint representation and the inference mechanism. In the last decade, 
CLP embedded many decision procedures from Mathematics, Artificial Intelligence 
and Operations Research and it offered many useful yet possibly incomplete 
contributions to several problem categories such as planning, scheduling, 
configuration, design and routing [2, 7, 9]. Generally, a CLP decision procedure may 
follow at least one of the three techniques, namely LP inherited techniques [17], 
Constraint Propagation techniques [17] and the Simplex-Like technique [11, 16]. 

LP inherited techniques, i.e. Generate and Test and Standard Backtracking, check 
constraint satisfaction after all the variables in the constraint are instantiated. 
Constraint Propagation (CP) techniques are mainly Generalized Propagation (GP) 
[20], Interval Reasoning (reals/integer) [4, 13] and Consistency techniques such as 
Arc Consistency [17], Forward Checking and (Partial) Look Ahead [24]. These 
techniques aim to detect failure early before all variables are instantiated, i.e. priori 
search. Simplex-Like is another type of CLP techniques whose features are inherited 
from the basic ones of its parents, i.e. CLP and the Simplex algorithm(SX) [23]. It 
inherits all CLP features while its search paradigm is ‘extremes search’ using pivoting 
operations similar to the Simplex algorithm. 

In the last few years, a diversity of researches have been investigated based on the 
integration between CLP and Operations Research for solving the optimization 
mixed-integer problems [8, 10, 14, 21]. These researches yielded hybrid systems 
which aim to enrich the modeling stage by the CLP declarative concepts, also, to 
improve the search efficiency of the hybrid system such that it performs better than 
applying each one of its counterparts solely. Our proposed system is a hybrid one in 
which the integration is met between three CLP techniques, precisely. Partial Look 
Ahead (Rational/Integer), Domain Splitting, and a Simplex-Like one. Its main 
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objectives are to minimize unnecessary backtracking, early discovery of failure, and 
to reduce pivoting operations as well as empower each counterpart to tackle the 
other’s defect(s). 

The rest of this paper is organized as follows. In section 2, we highlight the origins of 
our system techniques. Section 3 debates several controversial points of the foregoing 
techniques. Section 4 introduces the concepts that our proposed system is based on 
and summarizes the enhancements that our system submits to the underlying 
techniques. Section 5 presents the proposed system architecture and highlights its 
current implementation. The system performance is presented in Section 6, followed 
by our conclusions and the future view for the system in Section 7. 



2. The Reasoning Criteria of the Underlying Solvers 



2.1 Partial Look Ahead (PLA) Reasoning 



Definition 1 

A constraint C is interval-consistent [25] wrt D i ,. . ., D „ if, for each variable X ; and 
value Vi G (min(D i ), max(D i )), there exists values vi, ...,vi-i, vi + i, ...,v« in 

D 1 ,...,D i-i , D i + i,...,D n such that C(v 1 ,...,v n ) holds. 

On finite integer domain variables, PLA applies the following interval arithmetic 
formulas [19]: 

[a,b]H-[c,d]=[a-Hc,bH-d] 

[a,b]-[c,d]=[a-d,b-c] 

[a,b].[c,d]=[min(a*c,a*d,b*c,b*d),max(a*c,a*d,b*c,b*d)] 
and, if 0^ [c,d] then 

[a,b]/[c,d] =[a,b]/[l/d, 1/c]. 

By its definition, a PLA solver aims to remove inconsistent values from the 
boundaries only. The propagation, removing these values, is stopped whenever: 

• All inconsistent values from their domains’ boundaries are removed and 
domains are not empty. This is due to the sufficiency of model constraints used to 
reduce their involved variables. 

• A variable’s domain becomes empty. 

• The unification between variables’ domains has failed due to one propagation 
step. 

In the first case, the solver reaches the consistent state, while in the other cases, it 
proves the inconsistent state. 
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Definition 2 

A general model solution is a set of all unary-variable constraints that present all 
possible feasible (optimal) variables’ values generated when reaching a consistent 
state. A specific form of this solution named a specific solution is a subset, if any, of 
the corresponding general solution such that all constraints have their own equal 
bounds. 

Indeed, the solution generated by PLA is a general one, however, to generate all 
possible specific solutions, a user must submit to the solver a kind of labeler with 
his/her model. 



Example 1 

Consider the model of Xl=3-X2, X2=3-X1, Z=X1 h-X 2=3..3, XI in 1..3, X2 in 1..3; 
where the notation 1..3 is equivalent to [1,3]. 

1. Xl=[3,3] - [1,3] = [0,2] n [1,3] = [1,2]. 

2. X2=[3,3] - [1,2] = [1,2] n [1,2] = [1,2]. 

3. Z =[1,2] H- [1,2] = [2,4] n [3,3] = [3,3]. 

4. Xl=[3,3]-[1,2] = [1,2] n [1,2] = [1,2]. 

5. X2=[3,3] - [1,2] = [1,2] n [1,2] = [1,2]. 

6. Z =[1,2] H- [1,2] = [2,4] n [3,3] = [3,3]. 

Stop, the constraint store becomes stable. 

Now if a user uses a labeler to generate all possible specific solutions, then the solver 
gives Xl=l, X2=2 orXl=2, X2=l. 



2.2 Domain Splitting Reasoning 
Definition 3 

Domain splitting reasoning [24] is to split the domain of the variables into several 
parts, and the case analysis is achieved over the different parts, enabling rejection of a 
large set of values at once rather than testing them all at one time. 

The aim [4, 24] is to avoid instantiating the variables because it is believed to be too 
costly. The main characteristics of this reasoning are: 

1 . The stopping criterion depends on the number of times that the domain of the 
variable may be subdivided. The number may be related to making the splitted 
variable an instantiated one or even to make it range over the smallest subinterval of 
its domain. In the last case, the final interval(s) may indicate successful state 
however it doesn’t ensure reaching the actual answer in that interval(s). 

2. The user should specify explicitly the stopping criterion, and the variable(s) 
required to split. Then he/she submits these parameters to the solver in order to use 
them when it solves the related model. 

We present the following algorithm [4] as an example to how nowadays systems 
apply domain splitting technique. 
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Algorithm 1 

1 . Let Depth is the number of times, as the user specification, that the variable X in 
Lo..Up be desired to split; X, Lo, Up G R , and Depth G N 

2. If Depth = 0 then 

Goto 4. 
else 
begin 

• Depth =Depth- 1 

• Mid = (Up+Lo)/2 

• set X in Lo..Mid or X in Mid.. Up 

end 

3. Goto 2 

4. End. 

2.3 Simplex-Like Reasoning 

In addition to utilizing the CLP features stated in Section I, many Simplex-Like 
solvers add their own features whose objective is to reduce the size of the Simplex 
tableau and hence to improve the search efficiency [3, 16]. One of the most famous 
Simplex-Like Solvers is CLP(Q) [11, 12]. 



Definition 4 

CLP(Q)[11] is a solver that computationally benefits from the generalization form of 
the classical Simplex algorithm in which unary-variable inequalities are treated 
without introducing a slack variable for each. Thus a slack variable, if any, results in a 
basis that consists of multi-variable inequalities. 

The solver aims to maintain the solved form, i.e. to keep all non-basic (independent) 
variables at their lower or upper bound and the basic (dependent) variables ones 
within their bounds. To facilitate its concept, CLP(Q) introduces a new data type, 
called attributed variable [11] to assign for each model variable the corresponding 
information. 



Example 2 [12] 

Consider the input constraints of X< 10, X < 8, X > 2. 

In the classical Simplex, its table contains rows: X-tSl=10, X-tS2=8, -X-t-S3= -2. 

In CLP(Q), instead of introducing three slacks with their corresponding rows in the 
simplex table, the bounds are represented as attributes of the affected variable 
directly. Thus the solution will be X [ 2 , 8 ] . 

To solve the mixed-integer optimization problems, CLP(Q) uses Branch and Bound 
(BB) [23] method, which benefits from its mechanism of dealing with unary-variable 
constraint. 
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3. Constraint Propagation (CP) vs. Simplex-Like 

Whether CP techniques or Simplex-Like one is preferable to tackle the problem at 
hand has been debated for many years ago. This argument concerns how each 
technique models as well as solves the problem and states that each technique may 
prove its surpassing over the other. While the former utilizes its nature to effectively 
model a MIFD problem, it fails to solve some problem instances. On the latter side, 
there is no contribution to the modeling stage, however, it solves deterministically all 
MIFDP instances but, on contrary to the former, it tends to discover failure late, 
which affects its efficiency. Recently, to overcome the involved counterparts’ 
defects, systems have been built on the integration basis between them. This idea has 
been applied on many optimization problems strengthening their efficiencies in 
comparison with other paradigms. 



Constraint Propagation Techniques for Solving MIFDP 

In spite of the fact that CP techniques assail all LP inherited techniques’ defects, 
which cost the search from useless backtracking to exhaustive search of the problem 
space, it sometimes doesn’t determine the problem solution instead it misleads a user 
with incomplete solution. 



Definition 5 

An incomplete solution is one that contains some constraints (goals) partially 
satisfied. These constraints are named floundering goals [24]. 

To be a complete technique, i.e. to generate all consistent specific solutions as well as 
to tackle the floundering goals defect, a CP technique may utilize at least one of the 
LP inherited techniques and/or the Domain Splitting technique. However, up till now 
as to our knowledge, it is the user’s responsibility to utilize a generator or domain 
splitting mechanism at the modeling stage, i.e. using a labeling mechanism or domain 
splitting should be stated explicitly in the model representing the problem in hand. 



Example 3 

Consider the model of X in 1..2, Y in 1..2, X Y. 

Applying PLA reasoning, the solver gives the solution X in 1..2, Y in 1..2. Thus, X 
Y is floundered. The user must submit to the solver the model coupled with a 
labeler. This is to make the solver try all possible values of X and Y and hence to 
discover the infeasiblity of the model. 

Indeed, trying to instantiate a simple integer variable by one of the LP techniques 
exhausts the search even with the care of the mentioned active factors. On the real 
variable side, trying to instantiate simple or even restricted form of it causes the 
process to fall into non-terminated state or fall into the round-off error. Domain 
splitting mechanism may be helpful to activate the instantiation process since it may 
be used as a labeler. Unfortunately, due to its current characteristics (Section 2), 
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Domain Splitting is not efficient, i.e. the size of the search tree may be huge due to 
the number of splitted variables and the number of subintervals of each. 

[4, 24] illustrate the above argument in details. Moreover, the reader may refer to 
Section 3 to comprehend how our proposed system tackles these problems and 
Section 5 for practical examples. 



Simplex-Like Technique for Solving MIFDP 

Despite its exponential behavior, like the Simplex performance, this technique 
discovers failure faster than the Simplex but slower than a CP technique. Like the 
Simplex, there is no mean to the floundering goals defect, actually, the solution, if 
any, is either specific or multiple or unbounded. 

Notwithstanding CLP(Q) mechanism implies the great exploitation of the variables 
boundaries to reduce the whole pivoting, it is a major weakness of CLP(Q) in case 
that most (all) of the variables are simple. In that case, the answer to the optimization 
problem is „no“ although there is a solution. 

[11, 12, 16] cover the Simplex-Like based systems in detail. For the reader who is 
interested in integrating CLP(Q) with CP techniques. Section 6 introduces many 
examples to satisfy such a demand. 



Hybrid Systems for Solving MIFDP 

These systems have been built based on the cooperation between the Forward 
Checking solver and a ready-made Operations Research solver such as CPLEX or 
FortMP. Indeed, the integration idea has an Operations Research attitude for solving 
specific mixed-integer optimization problems and requests the user to reformulate the 
submitted model as its paradigm states. Unlike CLP, these hybrid systems discover 
failure late. Moreover, the integration is not transparent in terms of constraint stores 
and hence it has a duplication of some model constraints, which are sent to both 
stores. 

[21] gives a thorough survey on the current hybridization concept. The following 
Section, which illustrates our system basis, introduces another type of hybridization. 



4. Our Proposed System: Design Basis 

4.1 Domain Splitting on Constraints 

Our idea is to split the simple variable’s domain on the right hand side (RHS) value of 
the first constraint, in which it is involved, instead of an arbitrary value, e.g. the mid 
point which is used by the existing domain splitting techniques. The domain splitting 
technique can benefit from this idea in two directions, namely: 
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1 . A good heuristic is to split a variable’s domain based on the right hand side value 
of a model constraint since the final solution of the variable is likely to be (nearby) 
this value. 

2. The splitting is controlled by the system automatically, implicitly and only when 
needed rather than the splitting of the current techniques which is done only when 
specified explicitly by the user in the model of the problem. 

Remark 1. Since we avoid unnecessary choice points, the number of branches of the 

search tree are a maximum of 2" * instead of m*2" ' as it is without the Partial 
Look Ahead technique, where n is the number of involved variables and m is the 
number of involved constraints. To compare with CLP(BNR), the number of its 

branches is a maximum of 2*“^ per model variable where sub is the number of 
subintervals, which are created recursively due to user-dependent splitting. 

Remark 2. Our view to a simple variable is that it is a variable whose range can not be 
determined by the user. Thus it is difficult for him/her to set its splitting parameters 
(Section 2). As a consequence, the system, using the aforementioned idea, splits the 
domain of such a variable in order to help the user to further determine the feasible 
area and to find the optimum solutions. 

4.2 The Integration between CLP Techniques 

It is a good idea to create a fully transparent integration between both CLP 
mechanisms, i.e. CP and Simplex-Like. The CP mechanism submits a feasible region 
tighter than the original region in the model, including rational as well as integer 
feasible points. This region covers both restricted and/or simple variables. Seeking the 
extremes, the Simplex-Like mechanism benefits from tightening of the boundaries to 
reduce its pivoting operations and to work as a labeler in a feasibility problem as well 
as the optimal one. The word „transparent“ refers to the constraints store, which 
should be global for both types of solvers. This integration enhances the Depth First 
Branch and Bound method [24] in case of optimality. To meet our system’s demand, 
the selected CP solver is CLP(FD) [5, 25], while CLP(Q) is selected to be the 
Simplex-Like solver. The selected solvers are efficient but insufficient for our 
requirements. 

On CLP(FD) side, the following features have been added: 

1 .Performing propagation on both integers and rationals. 

2. Supporting the implicit domain splitting mechanism when needed, i.e. when the 
solver is faced with a simple variable and it can’t determine its range while applying 
the Partial Look Ahead (PLA) technique. The idea of embedding our proposed 
domain splitting technique into the PLA technique is to empower each of the solvers 
to overcome the other’s defect. PLA, from its side, removes the impossible splitting 
choices for a simple variable. The splitting technique, on the other hand, overcomes 
the floundering goal defect of PLA, especially, when the system is faced with the 
problem of having too many simple variables. Actually, if PLA according to the 
submitted constraints can deduce a simple variable’s range, it removes the need for 
applying the splitting technique. 

3. The general and specific solution forms, in definition 2, are redefined to meet our 
demand (Definitions 6,7). 
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Definition 6 

A general model solution is a set of all unary-variable constraints that present all 
possible feasible (optimal) variables’ values and all multi-variable constraints that are 
remained (floundered) when reaching the consistent state. 



Definition 7 

A specific solution is a subset of the corresponding general solution represented as the 
following set of constraints: 

Xr^a±'^QXj Xr&Sl 
XjeSi 

lox < X < upx X G X 

a, aj, Xj ,Xr , lox , upx g R 

Where a set of the model variables X = 5 1 tJ 5 2 and 5 1 O 5 2 = ^ . 

By this definition, a specific solution is considered as the extreme in which all given 
model multi-variable constraints are equality ones. Moreover, a restricted form of this 
definition is a form stated in Definition 2 and hence a specific solution may be 
generated directly by PLA reasoning. 

On the CLP(Q) side, in addition to its role in solving optimization problems, it has to 
be empowered to find all specific solutions following definition 7 (Algorithm 7). It 
would be worth mentioning that the resultant solution(s) are important for decision- 
making. In case of rationals, it is good to have only these solutions instead of all 
problem solutions, which may be infinite. Also, in case of mixed types, it is 
necessary for these solutions to avoid violating the restriction that some (all) variables 
must take integer values. Example 4 below illustrates a specific solution for a model, 
as per our definition. 

4.3 Introducing Data Types 

In order to solve a MIFDP with the previous integration, it was decided to utilize the 
following unification algorithm over rationals and integers, which is similar to that of 
CLP(BNR)[4]. The algorithm explicitly supports different types of variables such as 
rationals, integers, and simple variables, which enhances the domain splitting 
mechanism (Section 4.1). Hence, three data types are introduced „intvar“ for an 
integer variable, „ratvar“ for a rational variable and „unrvar“ for a simple 
(unrestricted) one. 

Algorithm 2 

Consider X and Y as two logical variables. To unify X to Y, the following cases 
should be taken into consideration: 

Casel: if X and Y are both constants then 

if X == Y then the unification succeeds 
else it fails. 
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Case!: if X and Y are both „unrvar“ type then 

the unification succeeds after unifying one of them to the other. 

Case3: if X(Y) is „nnrvar“ type and Y(X) is intvar or ratvar then 

X (Y) unifies to Y (X) and hence becomes restricted to its domain and the 
unification succeeds. 

Case4: if X and Y have the same data type (except nnrvar) then 
if dom(X) n dom(Y)=D ^ <f> then 

restrict the domain of both variables to D, unify one variable to the other, 
and the unification succeeds, 
else the unification fails. 

CaseS: if X and Y haven’t the same data type and none of them is of type unrvar then 
if dom(X) n dom(Y) = D <j) then 

restrict both variables domains to D, taking into consideration that the 
valnes of D is snitable to both data types, nnify one variable to the other, 
and the unification succeeds, 
else the unification fails. 



Remark. When modeling a problem, via our system, the model constraints should be 
represented mathematically as any CP technique. Though it requires an explicit data 
type for each model variable, the system doesn’t need explicit labeling or domain 
splitting predicates. 



Example 4 

Consider the model of intvar([Xl]), unrvar([X2]), X1+X2 =< 1,X1=<1. The solution 
process is shown in Fignre 1 . 

X1+X2=<1,X1=<1 



X2=<y 


X2>^ 


X1+X2=<1, 


X1+X2=<1, 


X2=<1, 


X2>=1, 


X1=<1. 

i 


X1=<0. 

i 


T 

□ 


T 

□ 



Fig. 1. The search tree of example 4 

The general solntions: [X1+X2=<1, X2=<1, X1=<1], [X1+X2=<1, X2>=1, X1=<0]. 

Example 5 

1 .intvar([Xl]), XI =< 3/2. The general solution is XI in - oo ..1. 

2.ratvar([Xl]), Xl=<3/2. The general solution is XI - oo ..3/2. 
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3. unrvar([Xl]), Xl=<3/2. The general solution is XI -oo..3/2. The system doesn’t 
perform any splitting over XI since XI could be determined. 

4. ratvar([Xl]), ratvar([X2]), l=<Xl=<9/4, l=<X2=<9/4, X1<X2. The general 
solution is XI in 1.. 224/100, X2 in 1..9/4; the rational precision is 1/100. 
5.intvar([Xl]), ratvar([X2]),unrvar([X3]), Xl+X2+X3=< 3/2, XI >=l/2,X2>=l/2. 
The general solution is XI in 1.. oo , X2 in Vi.. oo , X3 in - oo ..0, Xl+X2+X3=<3/2. 

Example 6 

Consider the model of ratvar([Xl]), ratvar([X2]),.Xl+X2=<l, X1>=0,X2>=0. 

The specific solution is Xl=l-X2, X2>=0, X2=<1. Figure 2 describes the state. 




4.4 Conversational Rather Than Solitary 

In our system, the user is not only involved in the modeling stage but he/she can also 
interact with the system during the problem solving stage, i.e. after reaching the 
general solution(s) and before seeking the corresponding specific solution(s). Thus the 
user is allowed to add constraint(s) to the constraint store and to impose objective 
function(s) on the general solution(s) to obtain specific solution(s). This may redirect 
or reduce the problem search space before obtaining specific solution(s). Moreover, to 
enhance the interactive process, by its definition, the general solution mathematical 
representation gives the user the feasible region of the model. Such a user interaction 
during the problem solving stage allows the user to dynamically remodel the original 
problem into a more suitable form. Thus any shortage in the modeling stage is 
compensated in the solving stage. If a constraint, at run time, is added to restrict the 
model variable(s) till being singleton then the adding functionality becomes a labeling 
mechanism. This type of labeling is user-dependent at runtime, instead of at design 
time, which is preferable since it separates the modeling stage from the solving stage. 

Example 7 

In the 5* point of example 5, if a user requests from the system to enhance his/her 
original model by adding the two constraints of X2=0 and X3=0 at run time then the 
solution is Xl=l, X2=0, X3=0. However, if the user adds the two constraints of X2=l 
and X3=0 then the system reports no solution. 
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4.5 System Features 

As a consequence to the above, the proposed system adds various features to the 
existing CLP techniques in solving MIFDP, which can be summarized as follows: 

a) The PLA: 

• Supports finite domain as well as infinite domains. 

• Supports integers as well as rationals by type specifications. 

• Tackles the floundering goals defect by being enhanced with a Simplex-Like 
solver. 

Two) The Domain Splitting: 

• Is implicit rather than explicit, and when needed rather than by user specification. 

• Is oriented to obtain general solution(s) and then to find specific solution(s) when 
the Simplex-Like solver is used, while in other systems, it is oriented to achieve the 
specific solution(s) directly. 

• The Complexity becomes maximum of (2" 'h- the complexity of the Simplex- 
Like solver for each general solution; when needed). 

• Tackles its resultant floundering goals, if any, by calling the Simplex-Like solver. 
Three)The Simplex-Like solver ( CLP( Q)): 

• Fed with a model that has tighter bounds of variables than in earlier systems and 
hence its mechanism is enhanced in solving MIFDP by reducing its pivoting 
operations. 

• It may implicitly utilize the domain splitting mechanism in order to deal with 
simple variables. 

• If it is applied with Interval Reasoning at each branch and bound search tree node 
then the number of nodes will be reduced. 

• It may be applied on rationals/reals and/or integers as a feasible-Solution Solver 
for integers and rationals in getting the minimum set of equalizers. 

Four) The Labeling Mechanism: 

The user can introduce labeling at run time instead of only being specified in the 
model at design time as in all existing systems. 



5. System Architecture and Implementation Highlights 

5.1 General MIFD System Architecture 

Supporting an Error handler mechanism, our system consists of: 

1 .The Declarative Engine. 

2. The MIED Interpreter. 

3. The MIED Engine. 

4. The Arithmetic solvers, i.e. the MIFD General-Solution solver, the MIFD 
Enumerative solvers and the CLP(Q) solver. 

5. The User Model(s). 

6. The MIFD Adaptor. 
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Figure 3 presents the architecture of the proposed system, where the cube symbols 
represent the modules designed and implemented by us, the oval shape represents the 
user input, i.e. the problem model, and the semi-bold square refers to the modules that 
we partially implemented and partially used existing modules. Our implementation is 
in Sicstus Prolog 3#5. 




The User level 



The MIFD 
solver level 



The 

Declarative 

Environment 



Fig. 3. The General MIFD System Architecture 

5.2 The Declarative Engine 

It is the inference engine, which controls the execution of the derivation steps, the 
unification process and maintains variables binding. To this end, Sicstus Prolog 
3#5[22] has been used. 
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5.3 The MIFD Interpreter 

It is a meta-interpreter that follows algorithm 3. 

Algorithm 3 

1 . Starting a session will signal to all the modules start-of-session command. 

2. Ask the user to determine the required file of model(s). 

3. Ask the user to determine the required model from the loaded file. 

4. Send sequentially, i.e. command hy command, the model commands to the 
MIFD Engine till end-of-model. 

5. Receive the general solution(s) from the MIFD Engine, if any. 

6. Send a (general) solution to the MIFD Adapter. 

7. Receive the user-required orders(s), such as adding a constraint or finding 
specific solution(s) from the adaptor. 

8. Feedback with the MIFD Engine and repeat steps 6 and 7 till end-of-general- 
solution or a user-end-signal. 

End. 

In the previous algorithm, if an error is detected then report „no“ with the 
corresponding error message and execute end-of-session command. 

5.4 The MIFD Engine 

It is a module, called from the MIFD Interpreter, and does the following activities: 

1 . Act as an interface between the MIFD Interpreter and solvers. 

2. Responsible for the communication between the different solvers. 

3. Maintain the store of constraints during the solving process. 

4. Facilitate the modeling process by providing the user with some functions for 
identifying a constraint, variable type, and an objective function. Thus the MIFD 
Engine represents the kernel of the MIFD solver. 

Algorithm 4 shows specifically the engine mechanism. 



Algorithm 4 

1 . Receive the model, sequentially, from the MIFD Interpreter. 

2. Translate each model command into a set of primitive constraints and variables 
specifications, i.e. names, ranges and type. 

3. Send a constraint to the MIFD General-Solution solver in order to perform local 
propagation step(s) while maintaining its rationality and integrity constraint. 

4. If step 3 fails then go to step 3 trying another alternative(s), if any. If there is no 
other alternatives then report „no“ and execute end-of-session. 

5. Update the MIFD store i.e. variables frames and constraints frames. 

6. Send the resultant store to the MIFD Interpreter, which consequently sends it to 
the MIFD Adaptor. 

7. If the MIFD store is empty, i.e. all model constraints are entailed, then report 
„yes“ and execute end-of-session. 

8. Receive any requests from the MIFD Interpreter. 
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9. If a request needs adding a constraint then send it to the MIFD General-Solution 
solver else if it is a specific-solution request, i.e. an objective function or a request 
for feasible solution(s), then send it to the corresponding arithmetic solver. 

1 0.If step 9 fails then report „no“. 

1 1 .Go to step 8 till end-of-requests. 

12. Go to step 1 till (end-of-general solutions or a user- end-signal). 

13. If user-end-signal then report „yes“ and execute end-of-session. 

14. If end-of-general solutions and not (user-end-signal) then report „no“ and 
execute end-of-session. 

End. 

5.5 The MIFD General-Solution Arithmetic Solver 

It is a module that deduces general solution(s), if any, of the submitted model. The 
intended module, namely PLAD(QI) solver, is PLA for rationals and integers which 
implicitly supports the domain splitting mechanism as demonstrated in Section 4.1. In 
the current implementation, CLP(Q) is utilized within PLAD(QI) to automate the 
constraint store operations. 

Algorithm 5 gives the solver mechanism in more details. 

Algorithm 5 

1 . Receiving the user model constraints from the MIFD Engine. 

2. If there is no specific data type for the model variables or it has a duplicate one 
then fail and go to end. 

3. Analyze a constraint into its involved variables. 

4. Use a variable frame to include its name, type, and range. Create a new one for a 
new variable arrival. 

5. If type(variable)=unrvar then 

If (its bounds being indefinite) or (they both can’t be determined using the 
current constraint and by applying PLA to find any) then 
Begin 

• Use the constraint RHS to split the variable on it. 

• Create a choice point of two constraints (clauses) of the form (Variable >= 
RHS) or (Variable =< RHS). 

• Send the two constraints as two alternatives to PLAD(QI) via the MIFD 
Engine. 

End 

Else 

Update the variable bound(s) via the MIFD Engine if PLA alters any. 

Else If (type(variable)=intvar) or (type(variable)=ratvar) then 
Begin 

• Perform PLA on the constraints that involve that variable. During a PLA 
propagation step, the following actions should be carried: 

• Call CLP(Q) to calculate the rational operations. 

• Maintain the integrity constraint of the shared integer variables. 

• Update the variable frame via the MIFD Engine, if necessary. 

End 

6. Go to 3 till (end-of-variables or empty-store or contradict-in-store). 
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7. Go to 1 till (no-change-in-propagation or end-of-constraints empty- store or 
contradict-in-store) . 

8. If contradict-in-store then report „no“ and go to end. 

9. If no-change-in-propagation or empty-store then report „yes“. 

End. 

5.6 The MIFD Optimal-Solution Solver 

It is a module that applies BB(CP/SX) to solve optimization problems. We propose 
BB(CP/SX) as a modified Depth-First Branch and Bound method in which at each 
search tree node a CP technique as well as a Simplex-Like technique, namely 
PLAD(QI) and CLP(Q) respectively are applied. While the former reduces the bounds 
of variables, the latter takes these bounds to enhance its search without the need for 
inserting rows to represent bounds by utilizing the generalized slacks paradigm. 

For more specifications, algorithm 6 illustrates the solver mechanism. 

Algorithm 6 

1 . Receive, from the MIFD Engine, a general solution (GS) to obtain the specific 
solution(s). Also, accept the user’s objective function (Obj). 

2. Set the value of Obj, Valo/y , to -oo(oo) for maximization (minimization) 
problem. 

3. If all variables are singleton then 
Begin 

If they satisfy the integrity constraint then 
Begin 

• Node ohj <— the value of Obj at the current node (Val obj ). 

• If the Node o/y is more optimal than Val o*/ then 
Begin 

• Label the node success-fathomed-node. 

• ValoZy ^ — Node c*Zy . 

• Try another node in BB(CP/SX) search tree. Otherwise, i.e. there is no 
such a node, go to step 8. 

End else 

Label the node fathomed-node. 

End else 
Begin 

• Label the node fathomed -node. 

• Try another node in the search tree. Otherwise go to step 8. 

End. 

End. 

4. At the current node, if there is no solution then 
Begin 

• Label that node fathomed-node. 

• Try another node in the search tree. Otherwise go to step 8. 

End. 

5. Call CLP(Q) with the GS U Obj. 

6. If all variables are singleton then 
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Begin 

If they satisfy the integrity constraint then 
Apply the corresponding step 3 sub-steps. 

Else 

Begin 

• Apply BB method to the variable that caused this violation i.e. split 
over its value V such that two new nodes of GS= GS O' (X<[e ^ or GS= 

GS ( X > [y ]) are created. 

• Call PLAD(QI) with each GS alternatively. 

• Go to step 5. 

End. 

End. 

7. If step 6 fails then 
Begin 

• Label the node fathomed-node. 

• Try another node in BB(CP/SX) search tree. Indeed, the fail may occur due to 
floundered goals defect, because of PEA, or the unbounded situation of CLP(Q). 

End. 

8. If there is no success-fathomed-node then 

Report „there is no solution" and go to end. 

Else 

Display all values of the corresponding variables and the value of the 
objective function of the last success-fathomed-node. 

9. Go to step 1 till (end-of-user-requests or end-of-general solutions). 

End. 



5.7 The MIFD Feasible-Solution Solver 

It is a module based on utilizing BB(CP/SX) to solve a submitted model which has no 
objective function. The solver itself introduces a specific objective function, which is 
extracted from the submitted model. The idea behind the automatic introduction of an 
objective function is based on the idea of Phase I of the Two-Phase method and the 
concept of the standard form for linear programming [23]. The solver aims to find out 
the feasible solutions demonstrated in Section 4.2. 

The solver mechanism is introduced in algorithm 7. 

Algorithm 7 

This algorithm is the same as the previous algorithm with the exception that the 
model hasn’t been supplied with the user objective function and hence the following 
changes should be taken place: 

1 . Step 1 is modified to satisfy the aforementioned argument. 

2. Step 2 is replaced by: 

Call standardize_model(GS, NewGS) unless there is unavailable solution or all 
variables are singleton. 

3. From step 3 to step 9 are the same as the previous algorithm with no checking for 
the optimality at any step of them. 
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Alsorithm (standardize modeUGS, NewGS)) 

1. NewGS={). 

2. Enumerate GS constraint-by-constraint. 

3. If C is unary-variable then NewGS=NewGS tJ {C} . 

4. IfC = {LHS < RHS ) then (C = (LHS+Sc = RHS) withS->0and let NewGS= 
NewGS U{C,&>0}JD 

5. If C = (L//5> then (C = {LHS—Sc=RHS) with5c>0 and let NewGS= 
NewGS U{C,&>0}). 

6. \iC = {LHS=RHSithcn {C = {LHS+Sc = RHS)% withX>0and let NewGS= 
NewGS U{C,&>0}). 

7. Go to step 2 till end-of-constraints. 

8. Sum all constraints slacks and surplus variables into a function, say Ob^, let 
NewGS= NewGS u { mmQbj ) } . 

9. Return NewGS. 

End. 

One may notice that obj is unique and stable during a BB(CP/SX) search tree. This is 
because it depends on the stability of the submitted model multi-variable constraints. 
Actually, the stability of those constraints during a search tree is the branch and bound 
method paradigm. 



5.8 The MIFD Adaptor 

It is a module interacting with the MIFD Interpreter and performs the activities: 

1 .Receive the answer, if any, from the MIFD Interpreter regarding the input model, 
formulate it in a user readable form and send it back to the user. 

2. Interact with the user inquiries for any adaptation to the current solution such as 
adding or removing constraint(s). 

3. Interact with the user to find a specific solution, feasible or optimal ones(s). 

The Adaptor is introduced in algorithm 8. 

Algorithm 8 

1 . Receive general solution(s), say GS(s), from the MIFD Engine via the MIFD 
Interpreter. 

2. Accept the request from a user and deal with it accordingly. This could be one of 
the following cases. 

• Find all specific solution(s) without Objective function calling 
BB(CP/SX)/feasible-solution solver for rationals and integers. 



^ LHS is a left-hand side expression. 

^Adding artificial variable to present the associated equality constraint in the objective function, 
is an Operations Research paradigm[23]. 
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• Find all specific solution(s) with Objective function {Ob^ calling 
BB(CP/SX)/optimal-solution solver for rationals and integers. 

• Add a constraint c to GS calling PLAD(QI) with C to add it to the store. 

• If the request is no-require-adaptation then go to step 5. 

3. If MIFD Interpreter detects a failure in step 2 then it returns the corresponding 
message to the user. 

4. Go to step 2 till satisfying no-require-adaptation. 

5. Go to step 1 till (end-of-general solutions or a user- end-signal). 

End. 



6. Examples and Performance 

It should be worth mentioning that our system brings up promising ideas for solving 
MIFDP by which the involved techniques invade their defects. However, when 
implemented, the system was faced with some limitations, which make it an effective 
prototype rather than an efficient system; the reader may refer to Section 7 for more 
details. Thus the performance of the proposed system should be measured by how it 
tackles its counterparts defects towards new contributions to solve such a problem 
rather than runtime efficiency. The following collections provide the reader with the 
layouts of the proposed system coupled with its synonyms for some MIFDP cases 
executed by them. These layouts pinpoint the features of our system in comparison of 
the others. 

Example 8 

Consider the model of ratvar([Xl, X2]), X1 h-X 2=< 3/2, X1-X2>=1, X1>=0, X2>=0, 
Xl=<5, X2=<5. Without loss of generality, we assumed the rationality of all variables 
and the feasibility problem. 

• Our proposed system output is: XI in 1..3/2 with ratvar type,X2 in 0..1/2 with 
ratvar type, X1 h-X 2=<3/2, X1-X2 >=1. This output is just a model representation 
to tell the user that these constraints are remaining constraints in the store after 
extracting all possible information from the submitted model. 

• The CLP(Q) output: if it is solely applied on that model: {X1 h-X2=<3/2, XI- 
X2>=1,X2>=0}. 

• Applying any Interval Reasoning system over rationals solely, i.e. without the 
use of the domain splitting mechanism or the CLP(Q) system, returns only 
variables ranges, if any. 

Thus our system’s output is more readable than its synonym’s output since it shows 
the variables ranges as well as the remaining multi-variable constraints. Moreover, the 
user may then adapt the resulting model as required. For example, if a request of 
adding the constraint XI =3/2 is submitted then the solution will be XI =3/2 and X2=0, 
and there will be no need for seeking optimality since the solution is unique. 
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Example 9 

Consider the model of intvar([Xl, X2]), Xl+X2>= 5/2, X1>=0, X2>=0, Xl=<3/2, 
X2=<3/2. 

• Our proposed system answer is no. Actually, this means that there is no 
feasible solution and hence no need to seek optimality. 

• The CLP(Q) output, if it is solely applied on that model, is: {Xl+X2>=5/2, 
XI =<3/2, X2=<3/2}. This answer is due to the relaxation of the original model, 
i.e. assuming the rationality of variables. 

• Applying any Interval Reasoning system e.g. CLP(FD), solely, over integers, 
gives the answer „no“. 

Example 10 

Consider the model of intvar([Xl]), ratvar([X2]), Xl+X2>= 5/2, X1>=0, X2>=0, 
XI =<3/2, X2=<3/2. 

• Our system’s answer is the unique solution of Xl=l, X2=3/2. Since this is the 
only feasible solution, then it is also the optimum under any submitted objective 
function. 

• The CLP(Q) output; if it is solely applied on that model, is: {Xl+X2>=5/2, 
Xl=<3/2, X2=<3/2}. Now seeking optimality: 

• For Z=X1+X2, maximize(Z). The solution will be Z=5/2, {Xl=<3/2, 
X2=5/2-Xl,Xl>=l}. 

• For Z=X1+X2, minimize(Z). The solution will be Z=5/2, {Xl=<3/2, 
X2=5/2-Xl,Xl>=l}. 

• For Z=X1+2*X2, maximize(Z), The solution will be Z=4, {Xl=<3/2, 
X2=5/2-Xl,Xl>=l}. 

• Applying any Interval Reasoning system, solely, over integers as well as 
rationals, gives the answer of Xl=l, X2=3/2. 

Thus it seems that any system which applies the Interval Reasoning technique in the 
solving stage is better to solve problems similar to Example 9, in which the 
infeasiblity avoids the need for searching optimality. For Simplex-Like based 
systems, e.g. CLP(Q), or the nowadays hybrid systems to prove optimality, if any, it 
must pass through many branch and bound tree nodes till discovering that there is no 
solution for that model. On the contrary. Interval Reasoning system, e.g. our proposed 
system, doesn’t need such a tree. Moreover, applying Interval Reasoning on integers 
and rationals such as the underlining problem saves the required time for seeking 
optimality, given any objective function, since the model has one unique solution. 

Example 11 

Consider the model of unrvar([Xl,X2,X3]), X2+X3=5, 2*X1+X2-X3=12, 

X1-h3*X2+4*X3=10. 



Our proposed system’s answer is Xl=-3/4, X2=37/4, X3= -17/4. 
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• The CLP(Q) answer, if it is solely applied on that model, is XI =-3/4, 
X2=37/4, X3= -17/4. 

• Applying any Interval Reasoning system, solely, gives the answer of XI in - 
00 .. 00 , X2 in - 00 .. 00 , X3 in - oo .. oo and hence all model goals are floundered. 

Thus it is worth to notice that using CLP(Q) for solving such a problem(s) is a must to 

tackle the floundering goals defect of the Interval Reasoning based system. 

Example 12 

Consider the model of intvar([Xl]), ratvar([X2]), 2*X1-3*X2>= -9, 

16*X1h-7*X2=<52, X1>=0, X2>=0. 

• Our system general solution is: XI in 0..3 with intvar type, X2 in 0..5 with 
ratvar type,X2-tl6/7*Xl=<52/7, X2-2/3*Xl=<3. 

• If the user asks the system to enumerate solution(s) then it generates two 
solutions: Xl=l, X2=ll/3 or Xl=2, X2=20/7. For CLP(Q), this feature is 
unavailable, moreover, those of Interval Reasoning should submit a kind of 
labeling (domain splitting) mechanism that maintains the integer characterization 
and solution(s) may not be (nearby) boundaries as such, actually, it is system 
dependent. 

Example 13 

Consider the model of unrvar([Xl, X2, X3]), X1 h-2*X2h-X3=3, 2*X1-X2=4. 

• Our system’output is essentially the two constraints of Xl= 2-l/2*X2 and 
X3= l-5/2*X2, with the 4 alternatives of: 

• XI in 8/5. .1 1/4 with unrvar type, X2 in -4/5. .3/2 with unrvar type, X3 in 
-1 1/4. .3 with unrvar type. 

• XI in 1 1/4. .3 with unrvar type, X2 in 3/2. .2 with unrvar type, X3 in -4..- 
11/4 with unrvar type. 

• XI in 3.. 00 with unrvar type, X2 in 2.. oo with unrvar type, X3 in - 
00 ..-4 with unrvar type. 

• XI in - 00 ..8/5 with unrvar type, X2 in - oo ..-4/5 with unrvar type, X3 in 
3.. 00 with unrvar type. 

Now, for a user, it may be useful to select one or more alternatives and to seek 

optimality using an objective function. Assume the user selects alternative 4 and 

tests the optimality with Z=X1 h-X2h-X 3 and maximize(Z), the solution then 

becomes Xl=8/5, X2=-4/5, X3=3, Z=19/5. 

• The CLP(Q) output, if it is solely applied on that model using the same 
objective function, the answer is no. In fact, if the original model is fed by one of 
the variables bounds in any of the previous alternatives, e.g. alternative 4, then it 
will improve the performance of CLP(Q) to achieve the correct solution(s), as 
required. 

• Applying any Interval Reasoning system, solely, gives the answer of XI in - 
00 .. 00 , X2 in - 00 .. 00 , X3 in - oo .. oo and hence all model goals are floundering 



ones. 
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Example 14 

Consider the model of intvar([X,Y]), X=<3/2, Y=<3/2, X+Y>=5/2, Z=X+Y, 
maximize(Z). 

BB(CP/SX) applies PLAD(QI) which directly detects infeasibility as soon as the 
X+Y>=5/2 arrives precisely at the initial node. Figure 4 illustrates the search tree of 
the systems such as hybrid ones, which depend only on the original branch and bound 
method to solve such a problem. 

Z=3 

X=3/2, Y=3/2 




Z= 00 Z= 00 

Infeasible Infeasible 



Fig. 4. Applying the original branch and bound method 



Example 15 

Consider the model of intvar([Xl, X2, X3]), 3*X1+6*X2=<8, 3*X1+6*X2>=7, 
X1>=0, X2>=0. 

• Our system’s answer is no. 

• The CLP(Q) output is no. 

• CLP(FD), if it is solely applied on that model enters an infinite loop. 
Moreover, any Interval Reasoning based system will do the same unless it utilizes 
a check mechanism for infinite loops due to its propagation steps. 



7. Conclusions and Future Work 

Over 100 linear models and five relatively large-scale cases, which are extracted from 
sicstus\lib\clpqr\examples\mip file, have been applied using our system and all of 
them prove the above mentioned advantages. However, our system has various 
limitations, which restrict it from being a real system and can only be considered as 
an effective prototype for the hopeful system. These limitations are mainly due to the 
fact that the only utilization of CLP(Q) is through calling it with the ‘call_residue’ 
predicate, hence there was no fully transparent integration between the embedded 
solvers in our current implementation. Moreover, since the ‘call_residue’ accepts the 
constraints as a conjunction of goals while returns the remaining constraints in the 
result as a list of goals, some run-time cost has been incurred due to the 
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transformation of constraints from a list to a conjunction each time our system calls it. 
For a complete reference of the proposed system, the reader may refer to [1]. 

In order to achieve more advantages and to overcome its drawbacks, our intention in 
the future is to build a WAM-based abstract machine for the system which supports 
rationals, reals and integers with the automation of domain splitting over constraints 
right-hand-side values, when needed. Our system will be intended to enhance the 
delaying mechanism in order to solve the nonlinear mixed problem as efficient as a 
linear one. To gain minimal backtracking, as intended, heuristics should be also 
utilized. 
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Abstract. We investigate notions of observable behaviour of programs 
which include quantitative aspects of computation along with the most 
commonly assumed qualitative ones. We model these notions by means of 
a transition system where transitions occur with a given probability and 
an associated ‘cost’ expressing some complexity measure (e.g. running 
time or, in general, resources consumption). 

The addition of these quantities allows for a natural formulation of the 
average behaviour of a program, whose specification and analysis is par- 
ticularly important in the study of system performance and reliability. It 
also allows for an average-case analysis of programs’ complexity, which 
can be seen as a semantical counterpart of the average-case asymptotic 
analysis of algorithms. 

We base our model on the Concurrent Constraint Programming (CCP) 
paradigm and we argue that it can be an appropriate base for further 
developments oriented to the analysis and verification of average pro- 
perties. 



1 Introduction 

The analysis and verification of a system has a fundamental importance for the 
system development. The advantages of formal methods for these tasks are well 
known. Similarly, in the system performance evaluation one can benefit from 
a formal specification of properties expressing the basic performance measures, 
such as system throughput and average response time, along with methods for 
automatically verifying those properties, which are solidly built on some mathe- 
matical base. On the other hand, in the practical realisation of systems formal 
methods are not always the methods of choice, and very often ad hoc methods 
are preferred. One reason of this relies on the absence in most cases of a viable 
semantics to be used as a necessary base on which to build a formal deductive 
system. The most desirable requirements of such a semantics should be rigour 
and precision on the one hand, and simplicity and clarity on the other hand. 
While this is in general not a trivial task, it is relatively simple to achieve when 
the adopted language is a declarative one. 

Based on these considerations and with possible applications to programs 
analysis and verification in mind, we adopt in this paper the Concurrent Con- 
straint Programming (CCP) paradigm of yt/li'ibj . whose declarativity descends 
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from the clear ‘logical reading’ of programs provided by its denotational se- 
mantics E! We then extend the classical CCP operational semantics 
so as to include two quantities representing probabilities and ‘cost’ respectively, 
the latter being some measures for computational complexity. This augmented 
semantics is formalised in terms of two different notions: One captures the pro- 
babilistic I/O behaviour of a program by collecting the results delivered by the 
program executions together with a probability distribution expressing for each 
result the likelihood of being computed; the other associates to each result also 
an index of the complexity of computing that result. The first extension was 
already introduced by the authors in a previous work where it is called 
Probabilistic CCP (PCCP). The second notion is a further extension, and turns 
out to be particularly suitable for defining another kind of observables which 
captures the average behaviour of a program. This plays a fundamental role in 
the evaluation and modelling of many relevant performance and reliability indi- 
ces of probabilistic systems, where one commonly refers to the long-run average 
time required by the system to perform given tasks. By ‘long-run average’ it is 
therefore meant an average over an infinite period of time prrrmj . On the other 
hand, the average behaviour of a probabilistic program can also be captured by 
considering the average among all its possible results from a given initial store. 
We will show that this correspond to the ‘expected value’ of a suitably defined 
random variable expressing the particular notion of cost (time, etc.) which the 
average refers to. 

The two kinds of averages mentioned above (i.e. long-run average and expec- 
ted value) can be naturally formalised in terms of the augmented operational 
semantics we propose in this paper. The basic idea is that the PCCP mecha- 
nism for inferring probabilities can be used for determining the weights in the 
expected value of a random variable expressing the time, the latter being the 
quantity measured as the computational cost. This can be generalised to quan- 
tities other than the running time. The model we obtain can then be used as a 
base for the formal analysis and verification of probabilistic systems. We can use 
it for deterministic programs as well, provided that we assume an appropriate 
interpretation of the ‘average’, which here has to be meant as an average calcu- 
lated over the (possibly infinite) different inputs. We also give an example for 
this latter case, which shows some similarities with the average-case asymptotic 
analysis of algorithms. 

We present some special cases of augmented transition systems, each corre- 
sponding to the choice of a particular cost function. Various program properties 
can be defined in this way, from the simplest I/O behaviour to important ones 
like termination. We also define a probabilistic version of the latter property, 
which can be used for a more realistic analysis in all those situations where the 
classical notion of termination turns out to be ‘too strong’. 

Finally, we suggest a possible application of the augmented operational se- 
mantics for the analysis of probabilistic programs based on an appropriately 
defined abstract interpretation methodology, which we plan to develop as a fu- 
ture work. 
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2 Probabilistic Concurrent Constraint Programming 

2.1 Syntax of PCCP 

Probabilistic Concurrent Constraint Programming (PCCP) was introduced in 
its original form in m A prototype interpreter of PCCP to gain practical 
experiences was later implemented on top of Sicstus Prolog |^. The motiva- 
tion behind PCCP was the formalisation of randomised algorithms within the 
CCP framework. These algorithms are characterised by a “coin flipping” device 
(random choice) which determines the flow of information. Although algorithms 
incorporating randomness, such as those for calculating tt or more generally the 
integration of complicated functions, have been known in mathematics for a long 
time (e.g. Monte Carlo algorithms), it is only in the last decade that randomised 
algorithms have found widespread application in many different areas of compu- 
ter science, for example as a tool in computational geometry and number theory. 
Various randomised algorithms and procedures have been investigated since, of 
which we mention just a few examples: simulated annealing in combinatorial op- 
timisation genetic algorithms CHI, probabilistic primality tests in particular 
for use in crypto-systems and randomised proof procedures (e.g. for linear 
logic EH). The benefits of randomisation at the base of the tremendous growth 
of interest in such algorithms are simplicity and speed. For this reason the best 
known algorithms for many problems are nowaday randomised ones m- 

In PCCP randomness is expressed in the form of a probabilistic choice^ which 
replaces the CCP nondeterministic choice and allows a program to make stocha- 
stic moves during its execution. We also replace the implicit non-deterministic 
scheduling in the interleaving semantics of the parallel construct by a probabili- 
stic scheduler. This allows us to implement a kind of prioritised parallelism. By 
these constructs the element of chance is introduced directly at the algorithmic 
level without the need of any modification at the data level. Thus, the constraint 
system C underlying the language doesn’t need to be re-structured according to 
some probabilistic or fuzzy or belief system (see e.g. I24I25I or EEI), and we can 
assume the definition of constraint systems as cylindric algebraic cpo’s given in 
EH, to which we refer for more details. 



Table 1. The syntax for PCCP. 



A ::= stop I tell(c) | ask(ci) pf. Ai \ qi'. Ai \ 3^A | p(x) 



The syntax of a PCCP agent is given in Table E where c and are finite 
constraints in C. We will assume that C is countable. A PCCP program P is then 
an object of the form D.A, where D is a set of procedure declarations of the 
form p{x) : —A and A is an agent. 
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In the following we will sometimes use a shorthand notation for the guards 
in the choice by writing c ^ p : A instead of ask(c) p : A. 



2.2 Informal Semantics 

PCCP agents are the same as CCP agents but for the non-deterministic choice 
construct, which is replaced by the probabilistic choice 

0"=i ask(ci) Pi \ Ai, 

and the parallel construct, which is replaced by its prioritised version 

■■ U 



In the probabilistic choice, the probability associated with each alternative 
expresses how likely it is that, by repeating the same computation “sufficiently” 
often, the computation will continue by actually performing that alternative. 
This can be seen as restricting the original non-determinism by imposing some 
requirements on the frequency of choices. The operational meaning of the pro- 
babilistic choice construct is as follows: First, check whether constraints Ci are 
entailed by the store. This is expressed in Table El by d h Cj, where h is the 
partial ordering (entailment) in the underlying constraint system, and d repre- 
sents the current store. Then we have to normalise the probability distribution 
by considering only the enabled agents, i.e. the agents such that Ci is entailed. 
This means that we have to re-define the probability distribution so as only ena- 
bled agents have non-zero probabilities and the sum of these probabilities is one. 
In general, this can be done by considering for enabled agents the normalised 
transition probability. 

Pi 



Pi = 



Ehc- Pj ’ 



where the sum X]|-c Pi over all enabled agents. When there are no enabled 
agents normalisation is not necessary. There might occur the situation where 
Pj = 0 (all enabled agents have probability zero), in this case the norma- 
lisation will consist in the assignment of a uniform distribution to the enabled 
agents. Finally, one of the enabled agents is chosen according to the new proba- 
bility distribution pi. 

The intuitive semantics of the prioritised interleaving is very similar. Again 
we replace the (implicit) non-determinism of the scheduler, which has to decide in 
the interleaving semantics which agent has to be executed first, by a probabilistic 
version. This selection has to be made among all those agents Ai which are 
active, i.e. can make a transition. Then we have to normalise the priorities pi 
of the active agents. This normalisation is done in the same way as described 
above for the probabilistic choice. Finally, the scheduler chooses one of the active 
agents according to the new probability distribution pi. 

Note that in the definition of the transition relation/system (see Section |^J 
each transition (i.e. single computational step from one agent to its continuation) 
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will have a probability associated to it. This ‘forces’ a probabilistic treatment not 
only of the choice but also of the interleaving (parallel construct). For this reason, 
we opted in the design of the language for an explicit probabilistic definition of 
such a construct, which makes the language more flexible than the one we would 
obtain by keeping the classical (non-probabilistic) syntax of parallelism. This 
would result in our semantics in a scheduler which always chooses among all 
active agents according to a uniform probability distribution. 



2.3 Transition System 



Table 2. The transition system for PCCP. 




The operational semantics of PCCP has a simple definition in terms of a 
transition system, (Conf, — >p), where Conf is the set of configurations (A,d) 
representing the state of the system at a certain moment, namely the agent 
A which has still to be executed and the common store d; and the transition 
relation — >p is defined in Table El The rules given are closely related to the 
ones for (nondeterministic) CCP, and we refer to for a detailed description. 

Rule R1 describes the effect of tell(c): this agent always terminates succes- 
sfully with probability one, and the new store is the least upper bound of the 
constraint c and the (current) store d, i.e. cUd. Note that we use the agent stop 
to mark successful termination in contrast to other agents which might get stuck 
(e.g. because no guard is enabled). 

Both rules R2 and R3 refer to normalised quantities pi . These are the result 
of the a normalisation process as described informally in the previous section. 
More precisely, this process can be defined for a generic set of real numbers 
X = {xi}, as the process of replacing each Xi by Xi as follows: 
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Definition 1. Let x = ^^6 cardinality of X = {xi}. Then 



Xi = 



t tfx^O 

^ otherwise 



Rule R2 describes probabilistic choice. An agent Ai is called enabled iff its 
guard Ci is entailed by the store, i.e. d h c^. The normalisation process described 
above is applied only to the pfs associated to enabled agents, and the choice is 
then among the enabled agents. 

The following is an example of the effect of the normalisation process in the 
context of a probabilistic choice: 



ask(c) — >■ 2 : A 
O ask(d) — >• 1 : R 
0 true — >■ 0 : C 

In case both c and d are entailed the normalisation will assign the probability 
I to A and | to i? and 0 to C. If either c or d is enabled then the corresponding 
agent is executed with probability 1, while C still has probability 0. If neither c 
nor d is entailed by the store, then C will be executed with probability 1. 

Rule R3 describes a prioritised interleaving: Each time the scheduler has to 
select an agent to be executed, it will choose according to the probabilities Pi 
among active agents. An agent A is called active if it can make a transition, 
i.e. there exists {A',d') G Conf such that (A, d) — >p {A',d'). Note that there 
is no rule for a transition from the stop agent to any other agent, i.e. stop is 
never active. The normalisation process described above is applied to the piS 
associated to active agents. 

The following example illustrates the normalisation in the context of the 
parallel construct: 



The scheduler will select agent A with probability | each time it has to make 
a selection; while the probability for B being selected is only That means in 
practice that during the interleaving process A will get the CPU slot twice as 
often than B. We can rephrase this by saying that A will run twice as fast as B. 
In this sense the probabilities pi actually represent priorities. 

We can use this prioritised interleaving to implement a kind of sequentiality 
by assigning priority 1 to the agent to be executed first and priority 0 to the 
agent to be executed last. Thus, for example, the agent 

1 : A II 0 : R 

represents the sequential agent A; B, which executes B after A has been com- 
pleted. A sequential composition of more than two agents can be implemented 
in an analogous way by using the appropriate bracketing. 




218 A. Di Pierro and H. Wiklicky 



Example 2. The following example can be useful to clarify the operational se- 
mantics for the probabilistic choice and the prioritised parallel operator. Consider 
the two agents A and B defined as 

A = ask(c) — >■ I : tell(e) 0 true — >■ | : tell(d) 

B = tell(c), 

and their parallel execution | : ^ || § ■ B starting with the “empty” store true. 

The execution of the agent A depends on the current store: if c is entai- 
led, then A has a choice between executing tell(e) and tell(d), otherwise only 
tell(d) is enabled. Therefore, if A is executed with store true its behaviour is de- 
terministic: only one branch is enabled and the associated transition probability 
becomes p = 1 after renormalisation, i.e. we get 

{A, true) — (stop, d) . 



If A is executed with store c, both branches are enabled and therefore we have 
two possible transitions (the probabilities stay unchanged as they are normalised 
already) : 

{A, c) — >3 (stop, c U e) , 



and 



(A,c) 



(stop, cUd) . 



The behaviour of B is much simpler: it will always (deterministically) add c 
to the current store. So, in the store true the execution of B will result in the 
transition: 

(B, true) — >-1 (stop, c) , 



and in any other store d, it will simply add c to it: 



(B,d) 



(stop, d U c) . 



Note that in general any parallel combination of an agent C with stop is 
equivalent to just C because (as mentioned above) stop is never active. In par- 
ticular, a parallel composition of several stop agents corresponds to (successful) 
termination. 

These observations give us the derivation tree of (| : A || | : B, trite) as 
depicted in Figure Dl In this derivation there are two different types of bran- 
chings: The one at the top level reflects the selection of the scheduler for the 
execution of either A or B first; thus the left hand side of the tree corresponds 
to the interleaving A; B whereas the right hand side depicts the interleaving 
B] A. The lower level branching on the right hand side corresponds to the pro- 
babilistic choice of the agent A. The representation of both the two possible 
interleavings in the same derivation tree allows for a more compact description 
of the execution of the agent in question. It should nevertheless be clear that 
each interleaving originates a different derivation tree. 
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Rule R4 in Table □ deals with the introduction of local variables; we use 
the notation for the agent A with local store d containing information on x 
which is hidden in the external store (see for further details). Obviously, 

the transition probability p is not changed by hiding. 

In the recursion rule R5 for the procedure call p{y), we assume that before 
p{y) is replaced by the body of its definition in the program P, the link between 
the actual parameter y and the formal parameter x has been correctly establis- 
hed. In this link is elegantly expressed by using the hiding operation 3^ 
and one only fresh variable. As this is a deterministic operation the transition 
probability in this rule is one. 

Given two configurations C and C' we define a computational path leading 
from C to C and its associated probability as follows. 

Definition 3. A path tt of length n between two configurations C and C is a 
sequence of configurations C = C\,C 2 , . . . , C„ = C" such that for all i: Ci — >p. 
Q+i. We define the probability associated to a path tt as prob{Tr) = YYi^^Pi- 

We will denote by Path{C, C) the set of all paths between two configurations 
C and C'. 

We now define the transitive closure — >* of the transition relation — >p in 
Table El as follows. 

Definition 4. Let C,C' G Conf. Then C — >■* C iff Path{C,C') 0 and 

P=T.^^Path{C,C')Prob{'K). 
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2.4 Results and Observables 

The basic notion of observables, as in ESI, captures the exact results of both 
finite and infinite computations together with their associated probabilities. 

Given a PCCP program, we define the result TZp of an agent A and an initial 
store d as the (multi-)set of all pairs (c,p), where c is the least upper bound of 
the partial constraints accumulated during a computation starting from d; and 
p is the probability of reaching that result. 

7^p(A,d) = {(c,p) I (A,d) — >* {B,c) U 

{{U^di,UiP^) I (A4) — 

The first term describes the results of finite computations, where the least 
upper bound of the partial stores corresponds to the final store. Note that this 
includes both successful termination — i.e. when B = stop — and suspended 
computations — i.e. the agent in the final configuration is not the stop agent 
and is unable to make a transition. The second term covers the infinite results. 

Because of non-determinism, there might be different computational paths 
leading to the same result. Thus, we need to ‘compactify’ the results so as to 
identify all those pairs with the same constraint as a first component. This 
operation is formally defined as follows. 

Definition 5. Let S = {{cij,Pij)}ij be a (multi-)set of results, where Cij denote 
the jth occurrence of the constraint Ci, and let Pc- be the sum of all probabilities 
occurring in the set associated with Ci. The compactification of S is defined as 
follows, where the notation Pa = Pci denotes the sum of all the probabilities 
associated with Ci (in S): 

1C{S) = {{c^,Pcf) I Pa = EciPc, = EjPy}*- 

We observe that this operation may not always result in a probability distri- 
bution when infinite computations are involved. In particular, this may happen 
when the derivation tree has infinitely many infinite branches. This case needs 
a more complicated, measure-theoretical treatment which we will not develop 
here for lack of space. 

Now we can define the observables associated to an agent A and an initial 
store d as: 

Op{A,d)=K{np{A,d)). 

Note that this notion of observables differs from the classical notion of input/ 
output behaviour in CCP. In the classical case a constraint c belongs to the 
input/output observables of a given agent A if at least one path leads from the 
initial store d to the final result c. In the probabilistic case we have to consi- 
der all possible paths leading to the same result c and combine the associated 
probabilities. 

Example 6. In the example given above, we can immediately see from the deri- 
vation in Figure Q that the probabilistic result is given by: 

^ II ^ : B,true^ = | U d, U e, U c, | . 
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Compactification and the simple fact that dU c = cU d finally give us the 
probabilistic observables as: 



3 Quantitative Observables 

3.1 Cost Function and Properties 

In the context of this paper we are interested in modelling properties which are 
related to the cost of a computation. By “cost” of a computation we mean a 
measure for any kind of resource which can be used and consumed during the 
computation, such as time, memory, etc. 

In general, we will represent such a cost by means of a random variable: 

Definition 7. A cost function Q is a random variable on the constraint system 
C, i.e. a map Q : C i— >■ M from the set of constraints into the reals. 

The function Q can be static, i.e. it is fixed throughout the computation, or 
dynamic, i.e. it depends on the computational history. A dynamic cost function 
can then be represented as the limit of a sequence of cost functions, each of 
which is associated to a particular stage of the computation. 

Such cost functions allow us to calculate the resource consumption associated 
to each individual result of the execution of a program, as well as to calculate the 
average properties of the program. We distinguish between two types of average 
properties: One captures the average cost of the final results, and is modelled 
by the expected value, E(Q), of the random variable Q expressing that cost; 
the other one is related to the long-run behaviour of a program and captures the 
average cost, A{Q), of a single computation in the limit. We will refer to the first 
type as average properties and to the second one as long-run average properties. 

3.2 Augmented Semantics 

For dealing with dynamical cost functions we have to provide additional infor- 
mation about how the cost evolves during the computation. For this purpose we 
extend the transition system for PCCP given in Table El by associating to each 
transition step its computational cost defined by an appropriate cost function 
Q. The transition relation — expresses the fact that a transition between two 
configurations takes place with probability p and has a computational cost q, and 
is defined in Table 0 which gives a general definition scheme for such augmented 
transition systems. 

This leads to a new notion of results which extends TZp by giving for each 
computed constraint the information about its computational cost. In order to 
define this notion of quantitative results, it will be necessary — as we did for the 
probabilities — to appropriately collect the partial costs along a computation. 




: B, true 




c U d, - 
2 
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Table 3. A generic augmented transition system for PCCP. 



R1 (tell(c),d) — (stopjCUd) 

R-2 ask(ci) ->■ Pi \ Ai,d) — (Aj,d) 



R3 



(Aj,c) — {A'j,c) 






-p.pj \iii#i=i Pi ■■ ^i II Pj ■■ 4.c') 

(A,du3,c) (A',d') 

(3iA,c) (3fA',cU3,d') 

R-5 {p{y),c) — (A,c) 



j € [1, n] and d h Cj 



7 — TV j e [l,n] 



p{x) : —A G P 



Typically, we will have to sum up the costs for each transition along a computa- 
tional path (e.g. execution time), but in some cases it might be appropriate to 
use a different method (e.g. memory usage might be dealt best by looking at the 
maximum instead). Therefore, in the following we will use a generic collection 
method F. 

Due to non-determinism the same configuration may be reached via different 
paths. We therefore need a second method to combine the costs associated to 
the different paths in an appropriate way. A very common choice is to sum up all 
the costs. However, depending on the interpretation of the quantity in question, 
other choices might be equally reasonable. Thus, we leave the compactification 
method 17 unspecified as it depends on the specific application. 

Given a PCCP program, we define the quantitative results TZ{A, d) of an 
agent A and an initial store d as the set of all pairs {{c,p,q)}, where c is the 
least upper bound of the partial constraints accumulated during the computation 
starting from d; p is the probability of reaching that result; q is the associated 
cost. 



7^(A,d) = {(c,p,q) I (A,d) ^ 9 (H,c) 7^1 U 

{{Uidi,UiPT^ridT) I (Ado) . 

The symbol ® indicates the transitive closure of the transition relation 
— and is defined in a similar way as the transitive closure of — >p in Defi- 
nition 01 by applying the appropriate methods F and 17. A computational path 
in the new transition relation and its associated cost and probability are the 
obvious extension of Definition 0 

Definition 8. Let C,C G Conf. Then C ^C" iff APath{C,C) 0 and 
P = Y.^eiAPath{C,C')P'^ 0 h{TT) and q = 
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Note that in the set 7?.(A, d) tuples might occur which contain the same 
constraint, i.e. the same qualitative information. We can identify all such tuples 
by combining the associated costs in some appropriate way. 

The quantitative observables based on the quantitative results 7?.(A, d) are 
then defined by: 

= |(c,p,g) I p = 

where E and f2 is over all tuples in TZ{A, d) with the same constraint c. 

4 Observing the Average 

In this section we use the notion of quantitative observables defined in Section 0 
in order to formalise various properties which reflect some “average behaviour” 
of a program. This formalisation can be used as a base for performance model- 
ling and evaluation purposes, as well as for an average case analysis of PCCP 
programs. 

In the following we will define and investigate two different types of average 
properties. One of them is based on the expectation value of the cost function, 
while the other refers to the time average. We call the first type of properties 
average properties, and the second one long-run average properties. 

4.1 Expectation 

An obvious way to analyse the average behaviour of a program is to consider 
the average cost of its (compactifled) final results. 

E= p-q. 

(c,p,q)eO{A,d) 

Note that in the above expression, q is the value of the discrete random 
variable Q on the constraint system defined via the augmented transition system 

by 

Q{c) = q iff (c,p, q) £ 0{A, d). 

On the other hand, the probability information contained in the quantitative 
observables can be seen as a discrete random distribution on the constraint 
system P : C !->■ [0, 1], i.e. a map into the real interval [0, 1], defined by 

P{c) = p iff (c,p, q) £ 0{A, d), 

with EcgC ^(c) = 1- 

Therefore, the quantity E defined above corresponds exactly to the expectation 
value or mean of Q with respect to P: 

E = E{Q, P) = Y<P Prob{Q{c) = q), 

cGC 

where Prob{Q{c) = q) is the probability distribution given by P, and so the 
probability p associated to the constraint c in the observables 0{A,d). 
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4.2 Time Average 

An alternative notion of average behaviour is obtained by considering the average 
cost along a single computation of an agent A and an initial store d, 



(A, do) 



(Ai,di) 



This leads to the definition of a long-run average property as: 



1 . 

A = A{Q,d) = lim E{Qi,Pi), 

n—¥oo Ji • ^ 

2=1 



where Pi and Qi denote the probability distribution on the partial results and 
the cost function at the ith computational step, respectively. In the case of a 
static cost function Q, where for all i, Qi = Q, the above expression becomes 
simply: 

1 "■ 

A= lim - E{Q,Pi). 

n—^oo Ti • ^ 

2 = 1 

Note that the relevance of this notion is only to infinite computations; for ter- 
minating computations this average would always correspond to the probability 
distribution of the final configuration. 



Example 9. The concept of long-run average can be illustrated by a simple ex- 
ample inspired by the following legencQ: 



Once there was a man who had two sons and a precious diamond 
ring. On his deathbed he wanted to be as fair as possible with their sons, 
and so decided that the ring had to be owned by the two brothers for 
one year each. The argument of the father then was that each of the 
brothers would own “half the ring” without having to destroy it. 

The above scenery can be described by the following (deterministic) PCCP 
program: 

father{x) : — sonA{x) 

sonA(x) : — 1 : tell(y = [a|a:]) || 0 : sonB{y) 

sonB{x) : — 1 : tell(j/ = [&|a::]) || 0 : sonA{y) 

father {\\) 

First, the ring is given to son A, who marks his ownership by adding an ‘a’ 
to the history list and (after one year) passes the ring to son B who proceeds in 
a similar way. 

We can now ask for the average ownership of the two brothers. In order to 
do this we introduce two static cost functions: 



QsonA(^) — 



1 if ch y = [a\z\ 
0 otherwise 



^ Arguments like this are not just children’s stories but were seriously discussed by 
mathematicians of the 18th century when the problem of defining limits and results 
of infinite series was still unsettled m 
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QsonB{c} — 



1 if c h y = [h\z\ 



0 otherwise 



i.e. both brothers own the ring respectively, when the store implies that the local 
history list y starts with their marking. 

It is easy to see that the time average for both cost functions is i.e. with 



and similarly for son B. Therefore, we get for both sons the long-run average: 



Some questions arise naturally, which are related to the types of averages 
discussed above: Does the time average exist? What is the relation between 
expectation value and long-run average? How do averages depend on the initial 
configuration or store? A detailed analysis of these questions can be found in 
H5j, assuming a denotational semantics based framework. 

5 Examples 

In order to illustrate our methodology we present in this section some exam- 
ples showing how properties can be defined by means of a suitably defined cost 
function and corresponding augmented transition system. The first property we 
consider is the simplest one, namely the input/output behaviour. We show how 
both the classical and the probabilistic I/O observables can be formulated by 
means of an augmented transition system. We then consider an important pro- 
perty which is at the basis of many programs’ analyses, namely the property of 
termination. Finally, we propose two different ways to measure the complexity 
(computational length) of a program and we discuss each of them after having 
defined the corresponding augmented transition systems. 

5.1 I/O Observables 

Classical I/O. The notion of classical observables describing the input/output 
behaviour of non-deterministic COP programs can be reconstructed from the 
notion of quantitative observables ignoring the information on the probability 
and cost of a result. So, from the quantitative results TZ we can obtain a (multi- 
)set of constraints by replacing (c,p,q) by c. 

Another notion of I/O observables can be defined by ignoring the probabi- 
lities of the results and keeping only the information about their costs. This is 




we get 




A(t/sonX ; — lim A,^((i/5oy,x5 trwe) — 2 
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obtained by replacing in TZ each tuple (c,p,q) by the pair (c,q), where q is the 
cost constructed along each computational path by using some collection ope- 
ration. Of course, this property is not the most appropriate one to look at, if 
we want to compute any kind of (probability) weighted sum of costs, (i.e. the 
expectation value), as we would need it for an average case analysis. However, 
we can still use such observables for a a worst case analysis by looking at the 
smallest or largest cost of a result c. In this case the compactification operator 
to be considered would be f? = max or 17 = min. 

Probabilistic I/O. The standard PCCP observables defined in Section El can 
be obtained by simply ignoring the costs in the quantitative observables, that is 
by replacing (c,p,g) by (c,p). 

These observables can still be interpreted as quantitative observables by con- 
sidering the static cost function Q{c) = 0, for all c € C, together with F = E 
and f2 = E. 

Another way to reconstruct the standard observables of a PCCP program 
as some kind of quantitative observable is the following: Take an augmented 
transition system where the labels p and q are the same. If we then use for the 
collection F = II and for the compactification 12 = E the tuples in the resulting 
quantitative observables are all of the form (c,p,p), i.e. cost and probability are 
identical. 

5.2 Termination 

Program termination analysis is a fundamental one in the systems’ development. 
The common notion of termination considers a program as terminating if and 
only if all its computational paths are finite. However, in many situation this 
notion might be ‘too strong’, and a probabilistic formulation of that property 
could allow for a more realistic analysis of the system. Such a probabilistic 
formulation would tolerate the occurrence of an infinite computation provided 
that its probability of actually taking place is zero. 

In this section we define a notion of quantitative observables by means of 
which the property of termination can be formalised in both its classical and 
probabilistic version. To this purpose we introduce in Table 0 an augmented 
transition system where the cost function Q associates to each constraint the 
number of transition steps required to compute that constraint. 

The quantitative observables, Ot, we are interested in for analysing ter- 
mination are then defined by using summation for the cost collection along a 
computational path, i.e. F = E] as for the compactification of the costs in the 
final results we take the maximum of the costs associated to each computational 
path leading to the same constraint, i.e. 12 = max. Alternatively, we could use 
a weighted sum for Q. However, as our interest is only in distinguishing if a 
computation is finite or infinite, f2 = max suffices for our purposes. 

Based on the resulting observables Ot{-A,(I) we now define two notions of 
termination: One, which we call strong termination, corresponds to the com- 
monly assumed idea of a program with no infinite computations; the other one. 
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Table 4. Augmented transition system for termination. 



R1 (tell(c),d) — >1 (stopjCUd) 

R2 ask(ci) Pi : Ai,d) — >},. {Aj,d) 
(Aj,c) — >l {A'j,c) 



R3 



R4 



Pi : Ai,c) 



ypj \lb 



Pi : Ai II pj : A'j,c) 



(A,dU3^c) {A',d') 



3iA,c 



^3fA',cU3,d'^ 



R-5 {p{y),c) — {A,c} 



j G [1, n\ and d h Cj 

j e [^,n] 



p{x) : —A G P 



which we call probabilistic termination, considers a program as terminating if 
the probability associated to its infinite computations is zero. 

Definition 10. An agent A is called strongly terminating if all its computatio- 
nal paths starting from any given initial store d are finite, i.e. for all (c,p,q) G 
Ot{A, d) we have that q < co. 

According to this definition programs with only extremely unlikely infinite 
paths are classified as “non-terminating” . It would be more realistic to ignore 
possible infinite paths if their probability vanishes. This justifies the following 
definition. 

Definition 11. An agent A (executed from the initial store d) is called proba- 
bilistically terminating if the probability of an infinite path is zero, i.e. for all 
{c,p, oo) G Ot{A, d) the probability p = 0. 

The following example can be useful to clarify the difference between the two 
notions of termination defined above. 

Example 12 (Gambler’s Ruin). 

Consider the following PCCP procedure which implements a so called “Ran- 
dom Walk in one Dimension” illustrating what is also known as “Gambler’s 
Ruin” : 

walk{x, y) : — ask(a; yf y) — >■ 1 : walk{x 3- 1, y) 

0 ask(a; yf y) — >■ 1 : walk{x, y 3- 1) 

0 ask(a; = y) — >■ 1 : stop 

Let X be the number of won games (or number of pounds won) and let y 
be the number of lost games (or number of pounds lost) . Then we can interpret 
walk{l,0) as meaning that the game starts with a one pound stake and is over 
when all money is lost. 
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Elementary results from probability theory show that the game will terminate 
with a ruined gambler with probability 1, despite the fact that there exists the 
possibility of (infinitely many) infinite paths, (i.e. enormously rich gamblers). 

Although the observables OT{walk{l,0), true) include infinite computations 
(corresponding to infinite random walks), the sum of the probabilities associated 
to all finite paths (i.e. random walks which “return” to store x = y) is one, 
e.g. 1^^ . Thus, the probability of (all) infinite paths must be zero. As a 
consequence, this program, which classically does not terminate, does terminate 
in a probabilistic sense: If one continues playing, most certainly he will ultimately 
loose everything. 

As another example we consider a simple program generating all natural 
numbers and discuss its properties related to I/O behaviour and termination. 

Example 13 (Randomised Counting). 

Consider the following PCCP program: 

nat{x) : — true — >■ | : tell(a: = 0) 

0 true — >■ 2 : 3^(1 : tell(a; = s{y)) || 0 : nat{y)) 

The standard CCP I/O behaviour of this program abstracts from any consi- 
deration about the probabilities and the costs associated to each result computed 
by nat{x) (i.e. the natural numbers), so the classical observables corresponds to 
the set [TT): 

Oc{nat, true) = {a: = 0, a; = s(0), a; = s(s(0 )) . . . ,x = s"(0), . . .} . 

We can now be a little bit ‘more concrete’ and consider the information on 
the transition probability provided by the augmented semantics. We then get 
the probabilistic observables: 

Op(nat, true) = {(a; = 0, 1/2) , {x = s(0), 1/4) , . . . , (a; = s"“^(0), 1/2") ,...}. 

from which we can also see the likelihood that a given number is actually gene- 
rated. 

A further step will lead us to observe the number of calls to the procedure 
nat(x) that are necessary to generate a given number. We have then the ‘most 
informative’ semantics: 

Orinat, true) = {(a: = 0, 1/2, 0) , (a: = s(0), 1/4, 1) , . . . 

...,(x = s"-i(0),l/2",n-l),...}, 

where, according to our intuition, we can see that when n tends to infinity the 
probability vanishes, whereas the cost grows bigger and bigger. 

Although this program does not terminate in the classical sense (there exists 
an infinite computational path), it is probabilistically terminating as the proba- 
bility of a path with infinite length is zero. 
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5.3 Recursion Depth 

A crude measure for the running time of an agent is the recursion depth. The 
corresponding cost function can be defined by associating a non-zero cost to the 
procedure call as in Table 0 



Table 5. Augmented transition system for recursion depth. 




The notion of observables, 0}i{A,d), we obtain are defined by means of a 
collection method F, which is again just summing up, while fl is the weighted 
or average sum: 

Ec, Pi ■ 

Qi = , 

Ec, P^ 

i.e. the partial cost of a constraint Ci is the weighted sum of the cost collected 
over all possible paths leading to the same result or store containing Ci divided 
by the sum of the probabilities to reach that result. This is necessary in order 
to renormalise the probabilities appropriately. We can then use the resulting 
observables Ofi{A,d) to compute the average recursion depth. 

Note that this average recursion depth, could be computed perhaps in an 
easier way if we used the quantitative result TZr{A, d) instead of the quantitative 
observables Oii{A^d). The average length of all paths, taking into account that 
there might be several ways leading to the same result is obviously: 

{ci,Pi,qi)€'R.R{A,d) 




which, if we combine the partial costs leading to the same store cf. 



^Pi ■ Qi 



E^ 

Ec, P^ 



■ ■ Pi 
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allows us to compute the average based on the observables as: 

Ci^C Ci {ci,pi,qi)^0 R{A,d) 



Example I 4 (Randomised Counting, revisited). 

Consider again the PCCP program from Example El 



nat{x) : — true — >■ | : tell(a: = 0) 

0 true — >■ 2 : 3y(l : tell(a; 



s{y)) II 0 : nat{y)) 



The observables Oji{nat, true) coincidently coincides with Oxinat, true)): 



0}i{nat, true) = {(x = 0, 1/2, 0) , (x = s(0), 1/4, 1) , . . . 

...,(x = s"-i(0),l/2",n-l),...}. 

Based on On{nat, true) we can estimate the number of calls we can expect on 
average by executing the program nat{x) starting with store true: 

CO 

E{nat,true) = '^^. 

q=0 

From elementary discrete mathematics theory we know that this sum is finite 
and equal to 2 EDI- That is, this program, though classically not even termina- 
ting, has an average running time of just two iterations. 



Example 15 (Binary List Search). 

The following is a program which searches a given list for an element in the 
list. In order to simplify the presentation we assume a list of length 2^ for some 
k. 

search{x,list,n) : — ask(x = list[n/2]) — )> 1 : tell(i = n/2) 

O ask(x < list[n/2\) — >■ 1 : search{x,list[l : n/2], n/2) 

O ask(x > list[n/2\) — >■ 1 : serach{x,list[n/2 + 2 : n],n/2) 

As the guards of the three alternatives are mutually exclusive, this program is 
deterministic, despite its formulation as a (probabilistic) nondeterministic choice. 
Therefore, the notions of classical and probabilistic observables are quite trivial 
in this case. In fact, any call to search will always terminate after a finite number 
of steps, once x is found by establishing i as the “index” of x in the list with 
probability 1. 

A slightly more interesting observable is On{search), which for a given input 
X gives the number of recursive calls needed to find x. This is fixed once x is fixed. 
Thus the average behaviour of such a program can be estimated by comparing 
runs of the program on different inputs. 
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As an example, consider the case n = 4. Then we have four possible calls 
search{x, [1,2, 3, 4], 4) with a;=l, a; = 2, cc = 3 and cc = 4. It is easy to verify 
that they take respectively 2, 1, 2 and 3 steps (or recursive calls). 

Assuming a uniform distribution on the input values x, we can now compute 
the average running time of search by 

2 + 1 + 2 + 3 

E{search{x, [1, 2, 3, 4], 4), true) = = 2. 



We can obtain the same result by considering the corresponding probabilistic 
program 



searchall{list,n) : — true 
0 true ■ 
0 true ■ 
n true ■ 



search{l, list, n) 
: search{2, list, n) 
: search(S, list, n) 
^ : search{4, list, n) 

It is easy to check that the observables of searchall. 



OR(searchall{[l,2,i,A],A)) = {{i = 1,1/4, 2) , (i = 2, 1/4,1) , 

(z = 3,l/4,2),(z = 4,l/4,3)}, 

can be obtained from the observables of each call to search as: 

On{searchall{[l, 2, 3, 4], 4), true) = ^ [J On{search{i, [1, 2, 3, 4], 4), true), 

^ i=l 

and its average running time is again: 

E{searchall, true) = ■ q I {c,p, q) G 0}i{searchall, true)} = 2. 

We can generalise this result to n = 2^ by asserting that the program search 
has an average running time oi q = k = log n. Note that this is the asymptotic 
complexity resulting from the average-case analysis of binary search algorithms 
(cf. §6.2.1 of EH]). 

5.4 Entailment 

A more realistic measure of the cost of a computation should probably consider 
ask operator as a major contributor. The complexity of this operation depends 
on the concrete application, i.e. on the actual constraint system. It is nevertheless 
clear that the cost of a choice construct depends on the (number of) guards to 
be checked, and on complexity of checking each guard, which we can express in 
all generality as follows. 

Let C{d, c) be the cost of asking if c is entailed by the store d. There are 
several special cases which are of interest: 

— C{d, c) = C(c) i.e. the cost depends only on the complexity of the constraint 
to be checked for entailment. 
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— C{d,c) = C{d) i.e. the cost depends only on the complexity of the store. 

— C{d, c) = const i.e. the checking cost is independent of both. This means we 
are only counting how often we ask the store. 

Side effects (e.g. using information from previous checks) may complicate the 
situation even further but they are extremely implementation specific, and it is 
thus impossible to deal with them in general. 

An augmented transition system which registers the number of asks is given 
in Table El Here we assume that each test requires the same, constant effort 
C{d,c) = 1. It is only in rule R2 - the choice construct — where asks may 
appear, therefore it is the only transitions which have a non-zero cost q. 



Table 6. Augmented transition system for constant cost ask. 

R1 (tell(c),d) — >i (stopjCUd) 

€ [1, n] and d h Cj 
G [l,n] 

(A,du3^c) {A',d') 

(3iA,c) (3tA',cVA3^d') 

R-5 (p{y),c) — >°i {A, c) p{x) ■. -A £ P 



R2 (D:Li ask(ci) ^ Pi : Ai,d) {Ai,d) 

(Aj,c) — (A'j,c) 



R3 



)Li Pi ■■ Ai,c) 



.q 

^p-Pj 



Pi ■ Ai II pj : A',c') 



The definition of the observables again requires an appropriate collection of 
the costs (of asks) along a computational path. It is reasonable in this case to 
sum up the costs (i.e. the asks along each computational path), that is to define 
r = E, and to take for 17, the above introduced partial average (weighted sum) : 






Ecj Pi ■ 
Ec, Pi 



A more general augmented transition system which registers the costs of ask 
in a more general way is given in Table Q Here the general dependency of an 
ask on the complexity of the guard and the current store is expressed in rule 
R2 again, which states that the cost of a transition of a choice agent is always 
the combined sum of checking all guards. 

The observables are based on the same F and 17 as for the case of a constant 
cost. 
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Table 7. Augmented transition system for variable cost ask. 



R1 (tell(c),d) — >i (stopjCUd) 
R-2 ask(ci) -!► Pi : Ai, d) 

R3 



Pj 



{Aj, d) j G [1, n] and d h Cj 



||r=i Pi ■Ai,c) -^Ip. 



(A,du3^c) {A',d') 

(3iA,c) (3fA',cU3,d') 

R-5 (j}{y),c) — S-? (A,c) 



i c) {Aj,C ) ^ 

i^i Pi ■. Ai \\ Pj ■. A'j,c) 



R4 



p{x) : —A £ P 



6 Conclusion and Future Work 



In this paper we presented an operational semantics which captures the I/O 
results of a program with respect to their probability and cost, the latter repre- 
senting (some measure of) complexity or resource consumption of a program. 

The idea of a structural operational semantics where transitions are enriched 
by entities capturing some intended ‘cost’ (of the transition), although new in 
the CCP setting, was already explored within the realm of Process Algebra (see 
e.g. HZ]) and Stochastic Process Algebra (see e.g. j4i33l3l3?lil| and references 
therein). Within the area of (lazy) functional programs, the idea of a counting 
analysis as developed in also seems to bear some similarities to the work 

presented in this paper. 

We also showed how average properties can be naturally expressed by means 
of our augmented operational semantics. This provides a base for the specifi- 
cation and analysis of probabilistic properties such as the ones called in mu 
long-run average properties, and for an average-case analysis of the program 
behaviour similar to the asymptotic average-case analysis of the complexity of 
algorithms. 

We intend to further develop these ideas as part of a more general programme 
aiming at the definition of an abstract interpretation framework supporting a 
probabilistic program analysis as well as the analysis of probabilistic programs. 
Such a framework should result from the incorporation of quantitative features 
to the well-known Cousot one 0. It would also be interesting to compare this 
framework based on algorithmic randomisation with a similar approach based 
on “soft constraints” |^. 

Moreover, our augmented operational semantics can be used for developing a 
methodology for quantitative data flow analysis, where it is possible to estimate 
— in a way similar to statistical methods — probabilities associated to the pro- 
perties of programs, instead of asserting the properties in a conservative way. In 
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this investigation other programming paradigms, like functional and imperative 
programming languages, will also be considered. Not surprisingly we expect that 
this will profit from various approaches in Markov chain theory and and 

Markovian process algebras 

Further work will be devoted to develop a denotational counterpart of the 
operational semantics presented in this paper, which could be used as a base 
semantics for a quantitative program analysis as well. To this purpose we intend 
to exploit the semantics introduced in a previous work by the authors 
which considers linear spaces structures (Banach or Hilbert spaces of measurable 
functions) as domain of denotations, in line with earlier important contributions 
in the area of probabilistic semantics like the fundamental papers of Saheb- 
Djahromi |2], and Kozen m- 

A first result in this direction is the denotational model for average properties 
which refer to static quantities. These correspond to real- valued random variables 
whose definition is fixed when the process starts and doesn’t change during all 
its execution This context also allows us to incorporate results from ergodic 
theory in order to analyse the relation between the expectation value E and the 
time average A. 
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Abstract. Planning and scheduling attracts an unceasing attention of computer 
science community. However, despite of similar character of both tasks, in most 
current systems planning and scheduling problems are solved independently 
using different methods. Recent development of Constraint Programming 
brings a new breeze to these areas. It allows using the same techniques for 
modelling planning and scheduling problems as well as exploiting successful 
methods developed in Artificial Intelligence and Operations Research. In the 
paper we analyse the problems behind planning and scheduling in complex 
process environments and we propose to enhance the traditional schedulers by 
planning capabilities to solve these problems. We argue for using dynamic 
models to capture such mixed planning and scheduling environment. Despite of 
studying the proposed framework using the complex process environment 
background we believe that the results are applicable in general to other (non- 
production) problem areas where mixed planning and scheduling capabilities 
are desirable. 



1 Introduction 

The real-life applicability and challenging complexity of planning and scheduling 
attract a high attention among researches in various areas of computer science. 
Traditionally, the planning and scheduling tasks are solved independently using 
different methods and technologies. The planning task deals with finding plans to 
achieve some goal, i.e., finding a sequence of activities that will transfer the initial 
world into one in which the goal description is true. Planning has been studied in 
Artificial Intelligence (AI) for years and the methods developed there, like the 
STRIPS representation [13] and Graphplan planning algorithm [6], are the core of 
many planning systems. Opposite to planning, the scheduling task deals with the 
exact allocation of activities to available resources over time respecting precedence, 
duration, capacity, and incompatibility constraints [7]. Operations Research (OR) has 
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a long tradition in studying scheduling problems and many successful methods to deal 
with the problem were developed there. 

Recently, Constraint Programming (CP) attracts a high interest among both 
planning and scheduling community because of its potential for declarative 
description of problems with various real-life constraints. Constraint programming 
[2] is based on the idea of describing the problem declaratively by means of 
constraints, logical relations among several unknowns (or variables), and, 
consequently, finding a solution satisfying all the constraints, i.e., assigning a value to 
each unknown from its respective domain. It is possible to state constraints over 
various domains, however, currently probably more than 95% of all constraint 
applications deal with finite domains [18]. 

At the present time, scheduling is probably the most successful application area of 
CP [19] while application of CP to planning is not so spread [14]. The reason for this 
disproportion can be found in the conventional formulation of the constraint 
satisfaction problem that expects all the elements, i.e., all the variables and all the 
constraints, to be specified in advance. This is not an obstacle in scheduling tasks 
where all the activities are known beforehand, however, the plans are highly variable 
and it is impossible to predict which activities will be used in which combinations. 
Also, in some problem areas like complex-process environments we do not know all 
the activities in advance and the appearance of the activity depends on allocation of 
other activities to resources. In such a case the scheduler needs to be enhanced by 
some planning capabilities which complicate the constraint model. 

In [4] we analysed the main features of static constraint models when applied to 
problems in complex-process environments and in [5] we proposed the mixed 
planning and scheduling framework that can be used to solve these problems. In this 
paper we survey dynamic constraint models for solving mixed planning and 
scheduling tasks. These models are applicable to scheduling tasks where generation of 
new activities during scheduling is required. We study expressiveness and efficiency 
of the models and we give a comparison of the models using the typical problems in 
complex-process environment. The described models were studied in VisOpt 
scheduling project [3] whose goal is to develop a generic scheduling engine for 
complex-process environments. Nevertheless, we believe that the results are 
applicable to other areas like transport problems and pure planning. 

The paper is organised as follows. In Section 2, we specify the problem area and 
we list the typical problems of complex-process environments there. In Section 3, we 
explain the similarities and differences of planning and scheduling tasks and we 
describe how to mix both planning and scheduling into a single framework. Section 4 
is dedicated to the description of constraint modelling of scheduling problems. We 
classify the scheduling constraints there, describe the models of time and sketch the 
difference between representation of resources and tasks. In Section 5, we overview 
three dynamic constraint models for solving mixed planning and scheduling 
problems. The paper is concluded by some final remarks. 



2 Problem Area 

The problem area that we deal with can be characterised as a complex process 
environment where a lot of complicated real-life constraints bind the problem 
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variables. Typical examples of such environments can be found in plastic, 
petrochemical, chemical, pharmaceutical or food industries. The goal of the VisOpt 
planning and scheduling project [3] is to develop a generic scheduling engine that can 
be customised easily for a particular environment via the description of resources, 
demands, initial situation and required future situations. 

The problem domain can be described as a heterogeneous environment with 
several resources interfering with each other. Currently we are working with 
producers, movers and stores, later other resources like workers and tools will be 
added. The task is to generate (to plan) the activities necessary to satisfy the custom 
orders and other marketing requirements and to allocate (to schedule) the activities to 
the resources over time. 

There exist alternative resources for processing the activity and some resources can 
handle several activities at a time; this is called batch processing. In case of batch 
processing, we must consider compatibility and capacity constraints restricting which 
products and in what quantities can be processed, i.e., produced, moved, or stored 
together. Also the order of the activities processed by the resource is not arbitrary but 
the currently processed activity influences what activities can follow. Consequently, 
we must follow the transition patterns and assume the set-up times between the 
activities as well. The processing time is usually variable and there is defined a 
working time when the activities can be processed in the resources. 

Alternative processing routes, alternative production formulas and alternative raw 
materials are other typical features of the above mentioned industrial areas. In 
addition to the core products it is possible to produce some low quality products 
called by-products, typically during set-ups. The by-products can be used as a raw 
material in further production and there is a push to use them this way because they 
will fill-up the available storing capacity otherwise. Consequently we must schedule 
processing of by-products. During production of the core product some co-products 
may appear. The co-products can be used to satisfy other orders, they can be sold as 
an alternative to the ordered item, or they can be processed further as a raw material. 
Again, processing of the co-products must be scheduled because of the limited 
capacity of the warehouses where all the products are stored. Last but not least there 
is a possibility of cycling, i.e., processing the item for several times for example to 
change features of the item or just to clean up the store, and re-cycling, i.e., re-using 
of the by-products and the co-products as a raw material. 

Typically, the production in complex process environments is not driven by the 
custom orders only but it is necessary to schedule the production for store according 
to the factory patterns and the forecast. It means that the scheduler should handle 
some planning tasks as well. 
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Fig. 1. A complex-process environment with re-cycling 
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In scheduling projects the users deal with finding no arbitrary schedule but an optimal 
schedule. Usually a makespan is used as the objective function [8,9,10]. The idea of 
minimising the makespan, i.e., the maximum completion time of the activities, 
follows the assumption that shorter production time implies lower cost and lower cost 
implies higher profit. However, this is not necessarily true in many complex-process 
environments where expensive set-ups must be considered. Also, makespan may be 
used if all the activities are known in advance, but, again, this is not the case in many 
complex-process environments due to set-ups and production for store. Therefore in 
the VisOpt project the task is to schedule the most profitable production for fixed 
period of time (more precisely, we are looking for a schedule with a good profit). The 
profit is measured here by the overall production cost and by the price of selling the 
products delivered according to the custom orders. 

The solved problem hardly fits into any category of typical scheduling problems as 
used by Operations Research (OR) because many complex constraints make it hard to 
be tackled by pure OR methods. It also does not fit into any basic category of CP 
scheduling problems due to the dynamic characteristic when new activities appear 
during scheduling. Perhaps, it is closest to the group of resource constrained project 
scheduling problems [10,11]. Resource constrained project scheduling problem 
(RCPSP) is a generalisation of job shop scheduling [1] in which activities can use 
multiple resources, and resources can have capacity greater than one (more activities 
can be processed together). Nevertheless, the definition of RCPSP as well as of all 
other scheduling problems in CP still expects the set of activities to be known before 
the scheduling starts. Unfortunately, this is not necessarily true in the complex- 
process environments where scheduling the activity to a particular resource or time 
may introduce new activities to the system. Typically, using alternative processing 
routes, by-products, co-products, and production for store cause such behaviour. 
Using the foregoing planning phase provides a little help in such cases as we argue in 
the next section. 



3 Planning vs. Scheduling 

Although, planning and scheduling tasks seem very similar, they are defined 
differently and different solving technology is used. We first overview a conventional 
definitions of planning and scheduling and survey the traditional solving technologies. 



Planning. The traditional AI planning tackles the problem of finding plans to achieve 
some goal, i.e., finding a sequence of activities that will transfer the initial world into 
one in which the goal description is true [16]. It means that a description of the initial 
world, the (partial) specification of the desired world and the list of available 
activities make the input of the planner. A solution is a sequence of activities that 
leads from the initial world description to the goal world description and it is called a 
plan. 

Conventional AI planning techniques use highly specific representation and 
algorithms but there is a pressure to use more general search frameworks like CP [14]. 
The advantage of such general framework is wider applicability and availability of 
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ready-to-use methods. The specific features of a particular problem are then reflected 
at the modelling level only and not in the underlying search algorithms. 



Scheduling. The traditional scheduling task deals with the exact allocation of 
activities to resources (or resources to activities) over time respecting precedence, 
duration, capacity, and incompatibility constraints [7]. The set of activities, the list of 
resources, and the specification of the constraints make the input to the scheduler. The 
output of the scheduler consists of the exact allocation of the activities to the 
resources over time. 

Scheduling tasks are usually solved using techniques from OR and CP. Both 
frameworks expect the task to be specified fully in advance, i.e. all the problem 
variables and constraints must be known beforehand. Recently, new problem areas 
like complex-process environments use a partial specification of the problem that 
requires adding new variables and constraints during scheduling. 

In industrial life, the boundary between planning and scheduling is shifted and both 
tasks are more similar that could be a source of confusion. There is a marketing 
planning that has nothing in common with the above described AI planning. The task 
of marketing planning is to prepare the demands for production using the information 
about the custom orders and the market forecast. The output of the marketing 
planning, the list of demands makes the input to the production planning. The 
definition of the production planning is closer to AI planning, the task is to prepare a 
plan of production using information like available stock, BOM (bill of materials), 
and demands. The plan consists of the list of activities that are usually assigned to 
factory departments. Finally, there is a production scheduling which allocates the 
activities from the production plan to available resources over time. Nevertheless, it is 
possible to introduce new activities during production scheduling if necessary. 

As you see, the difference between production planning and production scheduling 
is fuzzier now; both tasks include generating of activities and their allocation to 
resources. The discrimination criterion is shifted to the resolution of resulting 
plan/schedule and to the different time horizon. While the production planning uses 
lower resolution (departments, days) and prepares plans for longer time period, the 
production scheduling prepares short-term high-resolution schedules (machines, 
minutes). The similarity of the production planning and the production scheduling 
brings us to the idea of using unified solving framework for both tasks. Nevertheless, 
there are other reasons to mix the planning and scheduling technologies. 
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Fig. 2. A traditional view of planning and scheduling in industry with separate modules 



Opposite to [17] and according to our experience we argue that in many current 
Advanced Planning and Scheduling (APS) systems the modules implementing the 
planner and the scheduler are independent. The separation of planning and scheduling 
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is natural; the planner generates the activities and the scheduler allocates these 
activities to available resources. However, there are also disadvantages of such 
decomposition and these drawbacks become even more evident in some problem 
areas like complex-process environments. 

First, backtracking from the scheduler to the planner is required if the clasl[] in the 
plan is found during scheduling or if the plan does not utilise the resources fully. Such 
backtracking is not desirable because it complicates the communication between the 
modules (the scheduler should inform the planner about the reason of backtracking) 
and it decreases the overall efficiency of the system. To restrict the number of 
backtracks we need a more informed planner which means the planner that uses 
similar information about the resources like the scheduler. However, this suppresses 
the advantage of low-resolution of planning. Another possibility to avoid 
backtracking is to postpone planning decisions until all necessary information is 
available. Planning with active decision postponement was implemented in the system 
Descartes [12] and we propose to postpone planning decisions even more to the 
scheduling stage. 

More informed planner can prevent clashes during scheduling but it is not able to 
prepare plans in the problem area where the appearance of the activity depends on the 
allocation of other activities to the resources. There are several examples of such 
behaviour in complex-process environments. First, there are special set-up activities 
that must be inserted between two production activities [15] to ensure set-up of the 
machine. Second, there is a processing of the by-products that are produced typically 
during the set-ups. Some schedulers omit handling of by-products but this could be 
dangerous if the by-products may fill-up the stores used for regular products. Next, 
there is a re-cycling that is usually applied to by-products but it could be used with 
regular products as well, for example to clear the store. Finally, there is a non-ordered 
production. In some sense, the production planner could generate activities for non- 
ordered production but to prevent clashes it is more reasonable to postpone planning 
of non-ordered production until the scheduler provides information about spare 
capacity of the resources. 

The discussions in the above paragraphs and sections justify our proposal of mixing 
the traditional planning and scheduling tasks into a single framework. Briefly 
speaking, we suggest enhancing the traditional scheduler with some planning 
capabilities; in particular, we allow generating of activities by the scheduler. We call 
this enhanced scheduler simply a production scheduler. We expect to preserve the 
separate marketing planner that generates the basic demands for the production but 
the production scheduler is authorised to generate new activities for non-ordered 
production too. 

The production scheduler consists of an activity generator (former planner) that 
generates the activities and an activity allocator (former scheduler) that allocates the 
activities to the resources over time (almost) immediately. By attempting to allocate 
the activity to the resource after its introduction we can detect the clashes sooner as 
well as we can remove some alternatives via constraint propagation that restricts the 
domains of activity parameters. See Figure 3 for proposed structure of the mixed 
planning and scheduling system. 



* Clash may be caused by choosing the bad alternative during planning which prevents 
allocation of activities to available resources. 
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The communication between the generator and the allocator is simple via single 
activities. The generator introduces an activity to the system and asks the allocator to 
schedule it. The allocator influences the generation of furfher activities by resfricfing 
fhe domains of paramefers for already introduced activities. It can also ask the 
generator to introduce new activities explicitly, e.g., to generate set-ups, transitions, 
supplying or consuming activities, if fhe required activity is not present in the system. 
The generator is driven by the set of initial activities that can describe the initial 
situation as well as the future demands generated by the marketing planner. Also 
notice that depending on the resolution of fhe scheduling we can use fhe same 
production scheduler both for the production planning and for fhe production 
scheduling as described above. Nafurally a different type of activities and different 
resources are used for production planning and for production scheduling buf fhe 
overall solving mechanism is the same. 
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Fig. 3. A general framework for mixing planning and scheduling 



4 Constraint Modelling 

In general, it is a good design principle to create a declarative and thus transparent 
model of fhe problem. All entities are described initially wifh the constraints that 
define their nature and the relationships between them. The search code is kept 
separate from this declarative model. Constraint Programming has a big advantage 
over other frameworks in declarative modelling capabilities. Some researches even 
claim that „Constraint programming represents one of the closest approaches 
computer science has yet made to the Holy Grail of programming: the user states the 
problem, the computer solves it“ [E. Freuder, Constraints, April 1997]. The modelling 
capabilities of CP are really fascinating and the constraint models are very close to the 
description of real-life problems. This simplifies the maintenance of the models as 
well as the introduction of domain dependent heuristics necessary to solve large-scale 
problems. However, designing a stable constraint model that can be used to solve 
real-life large-scale problems is also the biggest challenge of current CP. 

Scheduling is a typical application area of constraint programming and several 
standard constraint models to tackle scheduling problems can be identified. In this 
section we survey the features of these models that must be taken into account when 
deciding about the model for a particular problem area. 
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4.1 Constraint Classification 

The constraints appearing in scheduling applications can be classified into several 
groups. We classify the constraints using their role in the scheduling problem into 
three categories: resource, transition, and dependency constraints. Such categorisation 
helps in choosing the right constraint model because different models handle better 
the constraints from different categories. Thus, we may choose the appropriate model 
more easily using the information about the spread of constraints in the proposed 
categories. 

We concentrate on solving scheduling problems in complex-process environments 
here but we believe that such environments represent the typical problems in most 
scheduling applications. Thus we suppose that the proposed classification can be 
applied to other scheduling areas as well. 



Resource constraints. The resource constraints describe the limits of the resource in 
single time point. A typical example of the resource constraint is the capacity 
constraint stating how many activities can be processed in parallel or how many items 
can be stored together etc.: 

V Resource \/Time ^ consumes( Activity, Resource, Time ) < capacity(Resource,Time) 

Activity 

start( Activity )<Time<end( Activity) 



Compatibility (incompatibility) constraint is another example of the resource 
constraint. The compatibility constraint states what activities can be processed 
together, i.e., in other words what activities/items are compatible. For example, if the 
Activityl cannot be processed together with the Activity2 in the Resource, i.e., the 
Activityl is incompatible with the Activityl, then we can use the following 
compatibility constraint: 

\/Time consumes( Activity 1, Resource, Time) = 0 v consumes(Activity 2, Resource, Time) = 0 

While the capacity constraint is a „quantity type“ constraint (how many?), the 
compatibility constraint can be seen as a „quality type“ constraint (what?). 

In many traditional scheduling problems the resource constraints are very simple, 
e.g., single-capacity resources are used only. However, these constraints are important 
when multiple-capacity resources like stores or batch processors are modelled. This is 
the case of complex-process environments. 



Transition constraints. The transition constraints also restrict variables describing a 
single resource but opposite to the resource constraints they bind the variables from 
different time points. Typically, these constraints specify what future situations may 
follow the current situation. For example we may describe the transitions between the 
activities (thus transition constraints). If a machine set-up time is modelled using a 
special set-up activity (this is useful, if by-products are produced during the set-up) 
then the transition constraints naturally describe the insertion of the set-up activity 
between two production activities. 

The transition constraints are typical for complex-process environments with many 
set-ups but they do not appear in many other scheduling problems. 
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Dependency constraints: The resources in a typical scheduling prohlem are hardly 
independent so we must also describe the relations between the resources in the 
model. We call such relation a dependency constraint. The dependency constraints 
bind variables describing different resources at perhaps different time points. A 
typical example of the dependency in production scheduling is a supplier-consumer 
dependency. It specifies the relation between the activity supplying an item and the 
activity consuming the item. A special case of the dependency is the precedence 
constraint in task-centric models (see below). In other problems we may require two 
activities to be processed in parallel by two resources, for example two lecturers teach 
two equivalent courses in parallel etc. 

The dependency constraints are typical for many scheduling problems as they 
describe the relations between the activities belonging to a single task. Nevertheless, 
in problem areas like complex-process environments they may bind activities from 
different tasks as well. 

Naturally, the above presented constraint classification depends on what objects are 
chosen as resources. In complex-process environments we use several resources like 
producers, movers and stores but it is also possible to add other resource types like 
workers and budget. 




4.2 Modelling of Time 

Both planning and scheduling tasks deal with time as one of the parameters. 
Therefore modelling of time is necessary in most planning and scheduling 
applications. In general we may distinguish between two different views of time: 
discrete time and event-based time. 



Discrete Time. Perhaps the easiest way of modelling time is to divide the time-line 
into a sequence of discrete time intervals with the same duration. We call such 
intervals time slices. The duration of the time slice defines the resolution of the 
plan/schedule. 

It is expected that the behaviour of the resource within the time slice is 
homogenous, i.e., the important events like the change of activity appear at the time 
point between two time slices only. Consequently, if we model activities using 
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discrete time then the duration of the time slice must respect the duration of all the 
activities. More precisely, the duration of the time slice must be a common divisor of 
the duration of all activities^ If we work with activities that have no restrictions about 
their start and completion time then this requirement may lead to a huge number of 
time slices (high resolution) even if the duration of the activities is long (low 
resolution). Therefore, the discrete time model is used mostly in timetabling and in 
personal management applications where the time slices are specified directly by the 
problem area (like shifts in hospitals). 

In the discrete time model the variables describe the situation either at the time 
points or at the time slices. 

Event-based Time. Another view of the time line may capture only the important 
time points, so called events, when there is some change. We may either say that the 
duration between two consecutive events defines the activity or that the border 
between two consecutive activities is called an event. Therefore we speak about 
event-based time or activity based models. 

In models that use event-based time we describe the situation of the resource by the 
processed activity. Each activity is characterised by a chunk of variables that should 
include the start time and the completion time (or duration) of the activity as well as 
the resource where the activity is processed. 

Event-based view of time is preferable over discrete time when the density of 
events is not very large in comparison with the density of time points, i.e. when the 
ratio between the activity duration and the duration of time slice is large. 
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Fig. 5. Discrete time vs. event-based time in Gantt chart 



4.3 Task vs. Resource Models 

A final criterion that we use to distinguish between constraint models is the primary 
organisation of elements in the model. In particular we mean organisation of activities 
but we can organise time slices this way too. We distinguish between two main 
categories: grouping of activities per task or per resource [7]. 



^ We must synchronise the time slices in all resources (because of dependency constraints); 
thus the duration of all activities in all resources should be assumed. 
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Task-centric models. In many scheduling problems the activities are organised into 
tasks where the task is defined by a group of activities that must be processed to solve 
the task. In production scheduling the task corresponds typically to a custom order. In 
such case we speak about a production chain that defines the track of the items 
through the factory starting from raw material and finishing with the final product. 
Note that by the production chain we mean not only a sequence of activities but also a 
tree of activities or other graph structure (typically with a partial order defined among 
the activities using the precedence constraints). Generating the production chain is a 
planning task while allocating the activities in the chain to available resources is a 
scheduling task. 

In the task-centric models, that are currently dominant in CP scheduling, the 
dependency constraints are preferred to the resource and transition constraints. We 
mean that it is easier to express the dependency constraints in such models as they 
describe the timing between the activities from single task typically using the 
precedence relation. It is more complicated to express the resource and transition 
constraints a priori because they are dependent on allocation of the activities to the 
resources. 

The task-centric model is appropriate for problem areas where we know all the 
tasks in advance and we know how to decompose the tasks into activities. However, 
in complex process environments, there exist problems like set-ups, re-cycling and 
non-ordered production that make the task-centric model less applicable because it is 
not clear what tasks will be present in the schedule (a non-ordered production) and 
what activities will form the task (alternatives, set-ups, re-cycling). 



Resource-centric models. Orthogonal to the task-centric model is the resource- 
centric model where the activities are organised per resources. In this model, we do 
not assign the activities to available resources but we order the activities in single 
resource in such a way that all the constraints be satisfied. In this model we describe 
the structure of the factory and the capabilities of the resources rather than particular 
tasks. The activities belonging to the task are grouped implicitly during the scheduling 
using the dependency constraints. Thus, the resource-centric model is re-usable for 
different sets of tasks and the same model can be applied to various sets of demands 
(tasks). 

Resource-centric model concentrates more on expressing the resource and 
transition constraints because we know which activities belong to a given resource. 
The dependency constraints are used to synchronise the resources and their 
appearance depends on the ordering of activities in the resources. Thus, these 
constraints have a dynamic characteristic. 

The resource-centric model is appropriate for problem areas like complex-process 
environments because it allows modelling set-ups, re-cycling, and non-ordered 
production. In this model it is natural to generate new activities during the scheduling 
so it is appropriate for solving mixed planning and scheduling problems. 

We described the classification of models via grouping activities per task or per 
resource but the same classification can be applied to the time points/slices as well. 
However, when the discrete time models are used, the task should be linear because 
otherwise it is more complicated to model the task using a single time line. 
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Fig. 6. Gantt chart is closer to the resource-centric model but we can identify the grouping per 
task there too 



5 Dynamic Models 

Conventional Constraint Satisfaction Problem (CSP) is defined statically; i.e., all the 
variables and all the constraints are specified in advance. Most methods for solving 
problems defined as CSP expect such static structure and they follow the schema: 

1. Introduce variables. 

2. Post constraints among the variables. 

3. Label the variables respecting the constraints. 

The main difference between the constraint satisfaction algorithms is in the labelling 
method; either they are extending a partial consistent labelling to a complete 
consistent labelling using constraint propagation or they are searching the space of 
complete (but inconsistent) labellings till the consistent labelling is found. 

Because of the static nature of the constraint models, the task-centric model is 
usually preferred over the more dynamic resource-centric model. Unfortunately, as 
we described in Sections 2 and 3, to model complex-process environments we need 
some planning capabilities within the scheduler and this requires the dynamic 
characteristic of the constraint model when new entities (activities, constraints) are 
introduced during scheduling In the following paragraphs, we describe three main 
constraint models used in scheduling and we propose how these models can be 
extended to solve typical problems in complex-process environments. 



5.1 Time-Line Model 

The time-line model is a general method of describing dynamic processes using 
discrete time intervals and grouping time slices per resource. As mentioned in the 
previous section, it is possible to combine discrete time with grouping slices per task 



^ We may use the static model to solve planning problems as well [4]. However, in such 
models all the possibilities must be captured which makes the model huge. This is because 
many variables are introduced to describe all the possible situations, but only few of them are 
really used. Also expressing the constraints is much more complicated and the value 
propagation is not very strong via such constraints. 
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too. However, this combination is rarely used because it requires „linear tasks“ only. 
Therefore we use discrete time and grouping per resource only in the following 
paragraphs. Such time-line model describes the factory in general because it 
concentrates on the specification of resources and it is independent of a particular set 
of tasks. 



Variables. We describe the situation of the resources at each time slice (time point) 
using a chunk of variables. These variables may specify the processed activity, the 
quantity of stored items etc. We may use a unified description of each time slice for 
the resource, i.e., each time slice for a given resource is described using the same set 
of variables. Another possibility is to generate (some) variables in time slices 
dynamically, e.g., in case of store we may introduce a variable for an item’s quantity 
when we know that the item is stored in a given time slice. By distributing the 
variables into static and dynamic groups we may preserve the propagation power of 
constraints (see next paragraph) while keeping the memory consumption low. A good 
strategy is to define variables present in all time slices for a given resource as static 
(like the variable specifying the activity) while the variables whose appearance 
depends on the value of other (static) variables as dynamic (like the quantity of a 
processed item). 

Remember that we are scheduling a fixed time period so we know the number of 
time slices. Consequently we know all the static variables in advance and we can also 
deduce their allocation in time. This simplifies capturing the initial situation of the 
resources as well as capturing the required future situations via setting the value or 
restricting the domains of variables. 



Constraints. The knowledge about the structure of (static) variables enables us to 
introduce resource and transition constraints in advance and to exploit the power of 
constraint propagation. The resource constraints bind variables in single time slice 
and transition constraints bind variables from consecutive time slices. If any dynamic 
variable is included in the constraint then the constraint is posted as soon as all such 
variables are introduced to the system. 

There remain the dependency constraints that express the supplier-consumer 
relations between the resources. These constraints bind variables from different time 
slices of different resources so they have dynamic nature here as their appearance 
depends on values of some variables. In particular, we can introduce the dependency 
constraint when we know which items are processed in the time slices. 



Planning. The role of the activity generator (the planning module) is shifted a bit in 
the time-line model because, in fact, we do not generate activities here. The activity is 
introduced simply by assigning a value to the activity variable at the time slice. The 
planning module in the time-line model is responsible for the introduction of the 
dynamic elements, in particular of the dependency constraints. 
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Complex-Process Environments. The time-line model is a very general model that 
is able to capture all the problems in complex-process environments as presented in 
Section 2. The problems like by-products, re-cycling, non-ordered production, or 
alternatives are modelled naturally here. Unfortunately, the size of the model is very 
large when applied to real-life large-scale problems. This is caused by the formula for 
computing the slice duration using the duration of all the activities (see previous 
section). In particular, even if the duration of the activities is, say 60 and 61 minutes 
then the duration of the time slice is still 1 minute (the greatest common divisor of the 
activities’ duration). Therefore many variables are redundant and, thus, we do not 
expect very good efficiency from this model when applied to complex-process 
environments. 



5.2 Task-Centric Model 

A traditional constraint model for scheduling problems in the CP framework uses 
event-based time with grouping of activities per task. We call this model simply a 
task-centric model. This model is very popular among the scheduling community 
because of its static nature; all the elements are known in advance. Also, typically the 
resource constraints are very simple here and there are no transition constraints. 
Unfortunately, this is not the case in the complex-process environments so we 
propose here how to extend the conventional task-centric model to solve some of the 
problems in such environments. 



Activities and variables. In the task-centric model, activities are used to describe the 
behaviour of the resources. Each activity is specified by a chunk of variables that 
include the start and the completion time of the activity (or duration) and the variable 
specifying the resource to which the activity is allocated. 

In the static representation, we have the description of all the activities in advance, 
but in complex-process environments we need to introduce activities during 
scheduling. There are two ways how to establish such dynamic behaviour. First, we 
may use a fully dynamic representation where the activities are generated by the 
planning module. Second, we may estimate the maximal number of activities per task 
and instead of using the fixed activities we propose to use a shell for activity, i.e., we 
extend the variable set in the shell by the variable for the activity. By assigning a 
value to this variable we fill the shell by the activity. We prefer this second 
alternative, called semi-dynamic representation, because it preserves the advantages 
of the static representation, i.e., constraint propagation, and it is almost as powerful as 
the fully dynamic representation^ 



In the fully dynamic representation, the number of activities in the task is not restricted at all; 
the decision about the activities is up to the planning module. In semi-dynamic representation 
we must decide about the maximum number of activities per task in advance wbicb may 
complicate modelling of cycling and re-cycling. 
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Fig. 7. In the fully dynamic representation (left), the planning module generates activities using 
the structure of all alternative production chains. In the semi-dynamic representation (right), the 
task of the planning module is to fill the prepared shells by activities using the chaining 
constraints (dotted lines). 



Constraints. In the task-centric model it is easy to express the dependency constraints 
between activities of a single task. Usually, these constraints express the precedence 
relation between activities of the task, i.e., which activities must be completed before 
another activity starts. Using fnlly dynamic or semi-dynamic representation 
complicates a bit expressing these constraints because we do not know the activities 
in shells. In such case, the constraints are posted as soon as the activity variable is 
assigned. 

In dynamic and semi-dynamic representations we may use another type of 
dependency constraint that binds activity variables. These constraints define the 
allowed production chains; in particular they are used to restrict the alternatives if 
some activity is known. Let’s call these constraints chaining constraints. 

Finally, there are resource and transition constraints that bind activities from 
different tasks. Again, these constraints are dynamic; i.e. they are introdnced during 
scheduling when we know the allocation of activities to resources (when resource and 
time variables are assigned). 



Planning. The dynamic representation of the task-centric model is a nice example of 
mixed planning and scheduling framework; the planning module introduces activities 
that are allocated by the scheduling module. During planning we nse the information 
from the chaining constraints. The semi-dynamic representation can exploit the 
chaining constraints even more because the constraints reduce the domains of the 
activity variables automatically via constraint propagation. 

The planning module is also responsible for the introduction of resource and 
transition constraints. In particular, it must identify the activities from different tasks 
that should be connected using these constraints. The planning module also decides 
about inserting special set-up activities. 
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Complex-Process Environments. The semi-dynamic representation was proposed 
with respect to solve typical problems in complex-process environments. There is no 
problem with alternative production chains in single task; the planning module 
chooses the alternative by filling the shells during scheduling. 

As already mentioned, there is also no problem to use set-ups. We may simply 
include a set-up activity among other activities in the production chain [15]. We must 
just be careful to which production chain (task) the set-up activity is included. 
Typically, the set-up is inserted between two activities from different tasks. If there 
are no by-products then we may include it to the production chain of the second 
activity (or the first one, it does not matter). However, if any by-product is produced 
during the set-up then we recommend including the set-up activity to the production 
chain where the by-product is consumed. In case of co-products, we need even more 
advanced mechanism of sharing activities by two tasks. It is the responsibility of the 
planning module to identify the shared activities. 

Finally, there is a non-ordered production. Unfortunately, to schedule non-ordered 
production we need to introduce new tasks during scheduling. This is not allowed in 
the semi-dynamic representation or we must prepare „empty“ tasks in advance to be 
filled by activities of non-ordered production. 

The task-centric model is perfect for environments driven by orders where the 
tasks do not interleave too much. Also, the resource and transition constraints should 
not be too complicated. Even after enhancing the model, the capabilities of the task- 
centric model to solve problems in complex-process environments are limited. 



5.3 Resource-Centric Model 

Like the task-centric model, the resource-centric model uses event-based time but 
now the activities are grouped per resource. Therefore this model is closer to the 
description of real factory and it is independent of particular set of tasks. 

We may use a static representation of this model when all the activities in the 
resource are known in advance. In such case the scheduling task is to order the 
activities in the resource respecting all the constraints. Naturally, the expressiveness 
of the static representation is not very high and a dynamic representation is more 
natural for this model. 

Resource-centric model is orthogonal to the task-centric model so many techniques 
are shared between the models. However, we shall show that the resource-centric is 
more appropriate for complex-process environments as it can solve the typical 
problems in these environments more naturally. 



Activities and variables. Again, we describe the behaviour of each resource using 
activities and each activity is specified by a chunk of variables. These variables 
include the start and the completion time (or duration), the process quantity and the 
links to dependent activities. Notice that we do not need a variable for resource 
because the activities are grouped per resource but we need links to supplying and 
consuming activities for dependencies. 

Like in the task-centric model we may use either a fully dynamic representation 
where the activities are generated during scheduling by the planning module or a 
semi-dynamic representation with shells. In the case of semi-dynamic representation, 
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the upper estimate of the number of activities per resource must be computed. 
Remember that the scheduled period is fixed so we may compute this upper estimate 
using the scheduled duration and the duration of the activities (the shortest activity). 
Opposite to the task-centric model where this upper estimate may restrict the number 
of cycles, there is no restriction when the semi-dynamic representation is used here. 
Because the semi-dynamic representation exploits the power of constraint 
propagation, we prefer this representation here. 

Constraints. In the resource-centric model, it is easy to express the resource and the 
transition constraints because we know which activities belong to the resource. In 
fact, we have the sequence of shells per resource and the resource and transition 
constraints are used to restrict the domains of activity variables. 

There remain the dependency constraints that bind variables from the activities of 
different resources. These constraints are dynamic; i.e. they can be introduced when 
we know the allocation of the activities to the shells. Note that even if we know the 
activity in the shell, it is not easy to identify the dependent activities because the 
shells in other resources may not be filled yet and they may not be allocated in time. 

Planning. In the semi-dynamic representation, the role of the planning module is 
shifted from generating activities to introducing dynamic constraints. In particular, the 
planning module is responsible for finding dependent activities, i.e., grouping 
activities per task. We may post the dependency constraints early when the activities 
in the shells are not known exactly and when the allocation of shells in the time is not 
precise. In this case a lot of potential connections is generated but only one of them 
will be selected later to form the dependency. This approach is close to the static 
representation. Another approach is to identify the exact dependent activity by the 
planning module. The disadvantage is that if we find later that the chosen activity is 
wrong we must backtrack to find another dependent activity. We propose something 
in-between; i.e. we post the dependency constraints when we know the activity in one 
of the dependent shells. 

During posting the dependency constraints, the planning module uses the 
information about tasks to be scheduled. We mean, that the activities in the shells and 
the dependencies are not chosen „randomly“ to satisfy the constraints but the planner 
prefers the activities to satisfy the demands. 

Complex-Process Environments. The resource centric model has similar capabilities 
like the presented time-line model in modelling problems of complex-process 
environments. There is no difficulty to model set-ups and because the dependencies 
are generated during scheduling, there is no problem with by-products or co-products. 
Because the production chains (tasks) are not specified explicitly in advance we may 
choose the alternatives during scheduling. Finally, the scheduling is driven by user 
demands but we can introduce activities for non-ordered production without any 
difficulty. 

The resource-centric model exceeds the task-centric model in problem areas with 
complicated resource and transition constraints and where scheduling of non-ordered 
production is required. Depending on the resolution of the resulting schedule, it has 
lower memory consumption than the time-line model but it is also a bit complicated 
to express some constraints here. We believe that in general, the resource-centric 
model is the best model for complex-process environments. 
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6 Conclusions 

In the paper we gave a survey of constraint models for scheduling problems and we 
proposed how to extend these models by adding some planning capabilities. This 
extension was motivated by real-life problems in the area of complex-process 
environments. We highlighted several such problems that are too complicated for 
traditional methods and we showed that the mixed planning and scheduling 
framework could capture these problems. We analyse the basic techniques of 
constraint modelling in scheduling problems and we studied three different constraint 
models. We argue for using a dynamic representation that prevails over the 
conventional static representation in areas where appearance of the activity depends 
on allocation of other activities to resources. Also, the dynamic representation makes 
the model more transparent and simplifies the constraints. As a result, we choose the 
resource-centric model that balances the efficiency and expressive power when 
applied to large-scale problems in complex-process environments. 

The methods proposed in the paper are currently verified in the implementation of 
a generic scheduling engine for complex-process environments. This engine is being 
developed within the VisOpt scheduling project for InSol Ltd. 
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Abstract. In this paper we describe a new implementation of the Fi- 
nite Domain solver ROPE |^, called MROPE II. This new version was 
preceded by an implementation on top of Prolog |3| and a version using 
an early version of Mercury HD|. In the previous implementation Mer- 
cury was chosen for its speed, compile-time checking properties and fast 
reliable development. This previous experiment with Mercury was al- 
ready a success, still there were some problems: for an efficient execution 
backtrackable destructive assignment was needed. Later releases of the 
Mercury system P] contained such backtrackable destructive assignment 
and also impure declarations. This was all we needed for a new imple- 
mentation of ROPE: MROPE II. The performance of this new system, 
with a very high level implementation, approaches the performance of 
other well known systems. 



1 The Finite Domain CLP System MROPE II 

The constraints handled in our new implementation, can easily be deduced from 
the Mercury types in the interface of the solver: 

A constraint has the following type: 



:- type expression 



:- type constraint 



> num(int) 

var (f inite_var) 

+(expression, expression) 
-(expression, expression) 

* (expression, expression). 

> <>(expression, expression) 

=(expression, expression) 

=< (expression, expression) 
>=(expression, expression) 

> (expression, expression) 

< (expression, expression) 

/* A constraint encapsulated into an 
constraint should not be an equiv 
equiv(f inite_var , constraint). 



equiv 
again */ 



In contrast with the previous solver, indexical constraints are not part of the 
solver yet. Depending on the need of the applications such constraints can be 
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brought into the system very easily. Reification constraints on the other hand are 
part of the language in the format of equivalence. equiv(finite-var, constraint) is 
a true constraint if the first parameter is a boolean variable expressing the truth 
value of the constraint in the second parameter. This second parameter cannot 
be an equiv/2 constraint again. This is not really a restriction on the language 
and could be overcome with a small transformation. Reification constraints are 
quite powerful, they can be used as a more flexible stand-in for the cardinality 
constraint 

The type range used to specify a domain of a variable is a bit awkward, but it 
allows expressing the domains very easily. Also unbounded domains are allowed. 



type range > 

num(int) /* A singleton */ 

; int ( int , int ) 

/* An interval the bounds included */ 

; unnCint, range) 

/* A union of sin integer and a remaining range */ 
; uni (int, int, range) 

/* A union of sin interval made by the first two 
arguments and ainother rainge */ 

; inf /* An infinite domain open two both ends */ 

; uni (int, range) 

/* A union of am interval from minus infinity up 
to the first argument with the range */ 

; opl(int) /* An interval from -infinity to the argument */ 

; opr(int)./* An interval from the argument to infinity*/ 



The remainder of the interface defines methods to create new variables, add 
constraints, find solutions with an enumeration predicate. Also a method is pro- 
vided to retrieve the current value/domain of Finite Domain variables. 

The solver has an explicit current state, containing all finite domain variables 
and constraints. It has type fdstore. This store is initialised with the predicate 
init/1. 



pred init (f d_store) . 

mode init (f d_store_muo) is det . 

Every finite domain variable within the system needs to be created before its 
use. This can be done with the predicate new_var/4. 



pred new_var (f inite_var , ramge, fd_store, fd_store) . 
mode new_var(out, in, fd_store_mdi , fd_store_muo) is det. 

A new constraint is added to the system by calling add-Constraint/3. 

pred add_constraint (constraint , fd_store, fd_store) . 

mode add_constraint (in, f d_storejmdi , f d_storejmuo) is semidet . 
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Finally enumeration can be started with enum/6. 

pred emimdist (f inite_var) , var_selection_mode , value_sel- 
ectionjnode , backtrackjnode , fd_store, fd_store) . 
mode enumCin, in, in, in, fd_store_mdi,fd_store_muo) is nondet . 

Other variants of the enumeration exist: one in case of optimisation; one 
with preferred values for the variables; and one combining optimisation and 
preferred values. An example where enumeration with preferred values is useful 
is rescheduling. 

One can also request for the current domain of a finite domain variable with 
the predicate value^var. 

pred value_var (f inite_var , list(int), fd_store) . 
mode value_var (in, out, f d_store_mui) is det . 

The reader may have noticed that the predicates making up the interface of 
the solver use the modes fdstore-muo, fd^storejmdi and fdstorejmui. These mo- 
des use mostly -Unique and mostly-dead instantiation patterns mostly-unique 
and mostly_dead allow to specify that there is only one reference to a particu- 
lar value, and that there will be no more references to that value respectively. 
Mercury defines some standard modes for manipulating ’’mostly unique” values: 

7o mostly unique output 

:- mode muo :: free -> mostly_unique . 

7o mostly unique input 

:- mode mui :: mostly .unique -> mostly .unique . 

7o mostly destructive input 

:- mode mdi :: mostly .unique -> mostly .dead. 

fd-store-mdi is equivalent to mdi but specific for type fdstore. fdstore-muo 
relates to muo in the same way and fdstore-mui relates to mui. In our case it 
means that when a store has been used as a parameter with mode fdstorejmdi, 
the variable referring to this store can not be used in the remainder of the current 
predicate. A parameter used in a call as parameter with mode fdstorejmuo is 
known to be the only reference to the current store. The mode fd_store-mui 
means that the corresponding parameter is the only reference to that data, and 
the code of the called predicate will keep it that way. An important property of 
these mostly-unique and mostly-dead instantiation patterns is the possibility to 
use them in non-deterministic code. This is what mostly stands for. A parameter 
which is mostly-dead cannot be used in future code, and is therefore dead, but it 
could come alive again after backtracking. An example of a program using this 
MROPE II module can be found in Section 01 
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2 A Log of Previous Experiments 

2.1 Implementing a Finite Domain Solver in Prolog 

In Logic Programming, it is standard practice to implement enhanced Logic 
Programming languages in Prolog through meta-interpretation. The advantage 
of such an approach is that those features of the enhanced language that coincide 
with corresponding features of Prolog can be implemented through downward 
reflection. Only features of the language that require a treatment different from 
that in Prolog are reified in the meta-interpreter. However, it is well-known that 
this type of implementation may produce significant overhead. One of the main 
motivations of LP work on partial evaluation has been to remove this overhead 
through transformation. We refer to for ^ more extensive discussion on these 
issues. 

It has frequently been observed that an alternative solution, avoiding the 
need for partial evaluation, is to implement the enhanced language by means of 
a transformer which maps the enhanced language to Prolog. Denoting a meta- 
interpreter for the enhanced language as M and a partial evaluator for Prolog as 
PE, conceptually such a transformer can be defined as a program T, such that 
for every program P in the enhanced language: T(P) = PE(M(P)). The point 
raised in discussions on this topic is that writing T from scratch is often not 
significantly more difficult than writing M and should therefore be considered as 
a valid (and more economic) approach to implementing the enhanced language. 

In this version of the ROPE language such a “transformation approach” was 
taken. The Finite Domain CLP program is then transformed to Prolog program 
which contains calls to a Finite Domain Library. 

Passing Information Around. In case there is no extra information to be 
passed around such a transformation T is quite simple: wrapping the special 
features of the enhanced language in calls to predefined library predicates will 
do the job. Given the program: 

Example 1. 

a(X, Y) :- r(X) , c(X, Y) . 
a(X, Y) :- s(X, Y, Z) , a(Y, Z) . 
with r/1 and s/3 special calls. 

Then this would be transformed to: 

Example 2. 

a(X, Y):- takeCareOfFeature(r(X)) , c(X, Y) . 
a(X, Y):- takeCareOfFeature(s(X, Y, Z)), a(Y, Z) . 

If there is need for extra information to be passed around from one call to 
takeCareOfFeature to another then every clause of the program needs an extra 
parameter, and the clause must be renamed. For every predicate definition in 
the program a new clause is added with the original name of the clause which 
calls the transformed clause with the initialised extra parameters. Applying this 
technique to the example results in: 
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Example 3. 

a(X, Y);- initialise (Parameter In) , 

a_l(X, Y, Parameterin, ParameterOut) , 
results (ParamieterOut) . 
a_l(X, Y, Paramln, ParamOut):- 

takeCareOf Feature (r(X) , Paramln, Paraml) , 
c(X, Y, Paremil, ParamOut) . 
a_l(X, Y, Paramln, ParamOut):- 

takeCareOfFeature(s(X, Y, Z) , Paramln, Paraml), 
a_l(Y, Z, Paraml, ParamOut). 

In some cases such parameter passing can be avoided by instantiating the 
variables on which the special features of the language act, with the information 
to be passed. This technique is not general but is applicable in our case. Then 
we also have to rename the predicates, as we have to intercept the output of the 
program and reconstruct the output that the original program was supposed to 
produce. The compiled program then looks like: 

Example 4- 

a(X, Y):- 

getFreeVariables(a(X, Y) , Free), 
a_l(X, Y), 
printResults (Free) . 

a_l(X, Y):- takeCareOfFeature(r (X) ) , c_l(X, Y) . 
a_l(X, Y):- takeCareOfFeature(s(X, Y, Z)), a_l(Y, Z) . 

First the free variables are extracted from the query. After successful com- 
pletion of the program we print the results of the original program. The user is 
responsible for preventing Prolog from printing the internal representation of X 
and Y. This can be done by adding a fail to the query: a(X, Y), !, fail in case 
only one solution is needed, a(X, Y), fail if all solution are wanted. 

Of course with this kind of technique special care must be taken. Normal 
Prolog unification of the special variables must be prevented while transforming 
the program. Also the use of builtins on these special variables must be taken 
care of. 



The Finite Domain Library. Before execution of such programs above a li- 
brary must be provided. More specific for a finite domain constraint solver a 
predicate must be defined to handle a constraint to replace to calls to takeCa- 
reOfFeature/1. There are three predicates in the finite domain library: 

— getFree Variables/2. This predicate searches for the free variables in first 
arguments and stores them in a list in the second argument. 

— printResults/ 1 prints out the list of Prolog expressions while substituting 
the finite domain variable with their semantic value. 
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— takeCareOfFeature/1 (constraint__/l in our case) is by far the most inte- 
resting predicate of the finite domain library. This predicate instantiates 
domain variables to a specific structure, fulfilling the purpose of passing on 
relevant information for the solver, adds the constraint to the constraint 
store and activates the solver for checking the constraint. 

In the next subsections we explain how the store, containing constraints and 
domains, is kept. 



Representation of the Store. Within the constraint solver constraints and 
domains of Finite Domain variables must be stored in some way. These domains 
and constraints should be easily accessible. Domains are updated and used very 
frequently. Whenever a domain changes, constraints affected must be activated. 
As stated before, one alternative is to add to every clause an extra input and 
output parameter. The data structures in these extra parameters contain infor- 
mation on the constraints connected to the variables and the domains as well. 
Every finite domain variable then refers to this global data structure with a uni- 
que number. When information concerning a finite domain variable is changed, 
for example its domain becomes smaller, then the out parameter reflects these 
changes while it still contains the old information on the other variables. Such a 
working method results in efficiency problems as updates to this global store are 
dependent on the number of finite domain variables in the system. An example 
of such a data structure is a flat term where each argument contains informa- 
tion on one finite domain variable (in the sequel, we refer to this representation 
as ’’functor”). The unique number associated to each finite domain variable is 
the position of this argument in the functor. If the information on one variable 
changes then a new functor must be created where all arguments but one must 
be copied from the old functor. Time and place complexity of this operation is 
0(N), where N is the number of finite domain variables in the program. A better 
alternative is a tree structure. In this case the complexity of copying in case of 
changes is logarithmic in the number of existing finite domain variables. Unfor- 
tunately, also access without modification becomes logarithmic in the number of 
finite domain variables. 

Therefore we choose to instantiate each finite domain variable to a structure 
that contains both the domain of the variable and the constraints in which 
this variable is involved. Then extra arguments for every clause in the program 
containing information on the current state of constraints and domains are not 
needed. The access to the data on one variable, having the variable available, 
becomes independent of the number of variables. There exist several references to 
one finite domain variable, namely each constraint in which the variable occurs. 
As a result we cannot replace the finite domain variable with a new finite domain 
variable when its domain changes. For this purpose we will use open ended data 
structure^ Passing on information on constraints and domains through the 
domain variable itself is particularly interesting for our application, since we 
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we come back later to this matter, together with the time complexity issue involved. 
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need to propagate constraints as soon as some type of changes occurs to the 
domain of a variable. Thus, by instantiating a domain variable to a structure 
finiteVar (Domain, Constraint_Store), where Domain is a representation of the 
domain of the variable and Constraint_Store of all constraints in the store that 
contain the variable, easy access for propagation is guaranteed. Actually there 
are only four classes of constraints to be activated. 

— Constraints to be activated after every change to the domain of a variable. 

— Constraints to be activated after a variable becomes ground. 

— Constraints to be activated after the lower bound of a variable’s domain 
changes. 

— Constraints to be activated after the upper bound of a variable’s domain 
changes. 

Note that some constraints belong to more than one class. The structure for 
the constraint store is then easily chosen: store (Always, Ground, LowerBound, 
UpperBound). With Always the constraints that need to be checked whenever 
the domain of the associated variable changes. Ground the constraints that need 
to be checked as soon as the finite domain variable becomes ground and Lower- 
bound and UpperBound whenever the lower bound (resp the upper bound) of the 
domain changes. If we handle a new constraint we check for the operators used in 
the expression. An expression int(X), min(X) will lead to storing the constraint 
in the LowerBound constraint list of the variable X. dom(Y) tells the system 
to put the constraint in the Always constraint list of variable Y. ask(ground(Z), 
Gonstraint) will put the constraint in the Ground list of the variable Z. 

Suppose we have a small program: 

Example 5. 

/* 

suppose 9 animals are playing on the grass, Rabbits and Pheasants, 
24 feet can be seen, how many sinimals of each kind are there ? */ 
rabbits (R, P):- 
R + P = 9 
4*R + 2*P = 24 

In this approach these 2 constraints will be transformed to low-level con- 
straints: {P in 9 - int(R), R in 9 - int(P), P in (24 - 4*int(R)) div 2, R in (24 - 
2*int(P)) div 4)11 

After treating the 4 low-level constraints of the rabbit program we obtain 
the following instantiation of the finite domain variables P and R: 

Example 6. 

P = f initeVar (Domainl , store([], [] , [C2, C4] , [C2, C4] ) ) , 

R = finiteVar (Domain2, store([], [] , [Cl, C3] , [Cl, C3] ) ) , 
with 

Cl = P in 9 - int(R), 

^ int(R) means: the smallest interval including the domain variable R 
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C2 = R in 9 - int(P), 

C3 = P in (24 - 4*int(R)) div 2, 

C4 = R in (24 - 2*int(P)) div 4. 

(the values for the domains will be discussed below) 

These data structures are generated while the predicate constraint--/! from 
the finite domain library handles a new constraint. Note that the representation 
we choose here for the list of constraints is too simplistic. Since constraints can 
be added at any time of the execution we have to use open ended data structures, 
discussed below. 



Representation of the Domains. As we are going to reason on the bounds 
of the domains, add and subtract domains we need a representation which is 
convenient for this kind of computations. Therefore we choose a union of in- 
tervals. For example a domain with the values 1, 2, 3, 4, 8, 10, 11, 12 will be 
represented as 1..4 V 8. .8 V 10. .12 using the same operators as defined in the 
low-level language. A fresh finite domain variable is initialised with the domain 
0. .infinity. As we have to update the domains of the finite domain variables we 
also need a structure which we can update by further instantiating. Using an 
open ended list for explaining the principle, every finite domain variable then 
starts with the domain representation: [0. .infinity! -] 

For the rabbit problem: after adding the two constraints constraint! and con- 
straint2 both finite domain variables are instantiated as 
finiteVar([0.. infinity, 0..9 | _], Constraint_Store). 
after adding the two other constraints constraints and constraint4 the data struc- 
ture becomes 

P = finite Var([0.. infinity, 0..9, 3. .7, 5. .6, 6..6| _], Storel) 

R = finite Var([0.. infinity, 0..9, 2. .6, 3. .4, 3..3| _], Store2) 

As a result of adding the two constraints to the constraint store and letting 
them propagate the two variables become ground. How this result is achieved is 
explained below. 



Open Ended Data Structures. This subject has already been mentioned 
several times above: the part of the store connected to one variable cannot be 
replaced but should always be changed by further instantiating it. In case of the 
constraints a simple open ended list can be used. When adding a new constraint 
the end of the list is further instantiated with a new element, the new constraint, 
and a fresh variable becomes the new end of the list. Also, for some optimisations 
in the finite domain library and for implementing constraints like cardinality, 
there is need for removing constraints from the constraint store. This is solved 
by adding a free variable to every constraint. A constraint can be deactivated by 
instantiating this free variable to the atom ’old’. When activating constraints, 
after a domain of a finite domain variable has changed, such constraints must be 
skipped. Similar to adding new constraints to the store, the domain of the Finite 
Domain variable should be changed during computation. In principle this could 
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again be done with an open ended list. The annoying thing here is that access to 
the domain, and updating as well, becomes linear in the number of updates to 
the finite domain variable. Indeed when fetching the current domain, the whole 
list of old domains must be traversed until the last element before the open end 
is reached. In our implementation we used an open ended data structure based 
on trees, which we will call open ended trees. The access and update complexity 
of this open ended tree is logarithmic in the number of updates to the domain. 
Moreover an extra variable is reserved which is instantiated when the domain 
becomes a singleton, hence fetching the domain of a Finite Domain variable 
which has been assigned can be done in constant time. For the curious reader 
interested in this topic the code handling this feature is added: 

Program 1. 

getDomain (domain (Tree , Var) , Ratnge):- 7o Var is ground for 

( atomic (Var) — ^ Range = ..(Var, Var) 7o a singleton domain 
; f indRange (Tree , Range) 

). 

f indRange (Tree , Range) : - 

( nonvar(Tree) — ^ lookup (Tree, D) 

; upperbound (Limit ) , Range = ..(0, Limit) 7o still free 

). 

putDomaindnf o , Domain) : - 

( Domain = ..(Value, Value) — ^ arg(2. Info, Value) 

; argd. Info, Tree), insert (Tree, Domain) 

). 

/* An implementation of an open ended tree. It has an update and 
retrieval complexity logarithmic in the number of updates. The 
last value in the tree is always the right -most nonvar element 
in the tree. When updating the tree grows from left to right, 
while subtrees grow larger, such that logarithmic access is 
ensured. */ 

lookup (tree (Left, El, Right), Value) 

( var (Right) — >■ 

( var(Left) — ^ El = Value 
; lookup (Left, Value) 

) 

; lookup (Right , Value) 

). 

insert (Tree, Value) 

( nonvar (Tree) — > insertl (Tree , Value, 1) 

; Tree = tree(_. Value, _) 

). 

insertl (tree (Left , _, Right), Value, Depth) 

( var(Right) — ^ insert2(Left , Value, Depth, Right) 

; Depthplusl is Depth + 1, 

insertl (Right , Value, Depthplusl) 

). 
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insert2 (tree (Left, El, Right), Value, Depth, Back);- 
( var(El) — El = Value 

; ( Depth = 0 ^ Back = tree(_. Value, _) 

; Depthminl is Depth - 1, 

( var (Right) — 

insert2(Left , Value, Depthminl, Right) 

; insert2 (Right , Value, Depthminl, Back) 

) 

) 

). 

Queue of Constraints. A last data structure concerns the queue of constraints 
which were activated, but not used yet. This is an open ended list where new 
constraints are added at the end of the list. A desirable feature of such a queue 
is that a constraint can only appear once in the queue. For this purpose an 
unbalanced binary tree is used in the pure Prolog version. In an impure version, 
we have used a record database. Every constraint has a unique number. For 
every constraint in the queue this number is stored in the tree/database. 

2.2 Early Mercury as a Platform for a Solver 

At the time of this first experiment. Mercury ^ was a recent phenomenon in the 
field of logic programming: it was faster than other logic language implementa- 
tions (e.g. Prolog) and better suited for the development of large applications 
because of its compile time error detection capabilities. The implementation de- 
scribed in the previous subsection is a prototype implemented in pure Prolog jOj. 
This implementation will further be referred to as ROPE. This prototype lacks 
efficiency because its implementation doesn’t rely on any non-standard support 
of the Prolog implementation. On the other hand, this helped the development 
of the ideas of ROPE quite a bit. We believe that the reason for this inefficiency 
is partly the generality of Prolog (reversible, non-typed predicates) and partly 
the lack of support for data structures that can be updated at constant cost. 
When the new logic programming language Mercury emerged, it looked very 
promising to port our prototype to this new system. One of the advantages of 
Mercury is faster execution: type, mode and determinacy declarations allow to 
generate more efficient code. In this subsection we summarise the work presented 
in m and HH. 

A Preview on Efficiency Gain. As an initial experiment we ported the code 
computing intersections of domains. Then we compared the speed of the Prolog 
version on ProLog_by_BIM and the Mercury version on a Sparccenter-1000. 

About 40.000 intersections were computed. 

The table Q shows that it is reasonable to expect a 10-fold speedup when 
going from Prolog to Mercury, on the assumption that Mercury offers efficient 
pure alternatives for the tricks in the Prolog program. 
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Table 1. A preview on speedup 





ProLog_by_BIM Mercury 


40.000 intersections 


3.7s 0.36s 



Replacing Open Ended Data Structures. Replacing the open ended data- 
structures, heavily used in the Prolog version, was a hard job. Without using 
the C-interface for implementing other data-structures is was unavoidable to add 
extra parameters to the program passing information around about the state of 
the finite domain variables and the involved constraints. For representing this 
global state a Mercury array was used. To our surprise the program was slower 
than the Prolog version. In an attempt to find the reason for this inefficiency, 
different data-structures were tried in this global store: the arrays were replaced 
by binary trees and a plain functor. 

It turned out that this data-structure was significant as can be seen in table 

u 



Table 2. Changing the data-structure 





queens(lO) 


Mercury array 


47s 


bintree 


25s 


functor /20 


21s 



The execution time of the Prolog version being 39 seconds, the two new 
versions were faster than the Prolog execution. 



Using Backtrackable Destructive Assignment. Finally we decided to hack 
the Mercury system and add our own backtrackable destructive assignment. 
Then we could change the data on finite domain variables in-place, having a 
constant time access and update time-complexity. Next to this in-place modi- 
fication, we could also add a cardinality constraint to the system. With the 
additional cardinality constraints a wider range of examples was possible. 

For comparison the same code was executed in SICStus v2.1 using setarg/3 
because the ROPE system on ProLog_by_BIM and the implementation in Mer- 
cury now use totally different data structures. 

Table 01 shows a relatively bad result on the queens problem for the MROPE 
system. In the version of ROPE in Prolog the different from constraint is handled 
at a higher level, which allows some optimisation: a constraint X <> Y can be 
removed from the constraint store as soon as one variable is instantiated. This 
was not done in the Mercury version. 
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Table 3. The effect of backtrackable destructive assignment 





MROPE(Mercury) MROPE(SICSTUS) ROPE(BIM) pure MROPE 


queens 
bridge 1 
bridge2 
perfect 
suudoku 


21s 109s 39s 65s 

1.9s 10s 27s 5s 

1.7s 11s 14s 

23s 125s 126s 

1.2s 5.5s 6.8s 



So, ignoring the queens result, we observe that MROPE is 5 to 15 times 
faster than the original ROPE in Prolog. 

3 Using a More Mature Mercury 

As the Mercury system is a constantly evolving system, the Mercury system has 
become a lot more mature since the experiment reported in the previous section. 
In the current version (0.8.1) building stones for backtrackable destructive assig- 
nment and other features, like impure declarations, were included. This makes 
it possible to create an efficient but still high level implementation of our Finite 
Domain solver. 



3.1 Data Structures and Implementation 

A finite domains solver has three main data structures: 

— domains attached to the finite domain variables, 

— constraints and 

— a queue of constraints to be checked in the fixpoint algorithm. 

For all operations on these data structures: creation, retrieval and update, it is 
important to achieve constant time operations. In this section we will show that 
Mercury allows to define and use such data structure with a minimum of low- 
level programming. The low-level programming concerns the use of backtrackable 
destructive assignment. A small module mutable defines such operations: 

:- module mutable. 

:- interface. 

:- type mutable(T). /* a polymorfic mutable object */ 

:- pred mutable__init (mutable (T) , T) . 

:- mode mutable__init (out , in) is det . 

/* create a new initialised mutable object */ 



:- pred mutable__overwrite (mutable (T) , T) . 
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mode mutable__overwrite (in, in) is det . 

/* Overwrite the current contents of the mutable 
object with new data. When the system backtracks 
over this operation the old data is restored */ 

pred mutable__get (mutable (T) , T) . 
mode mutable__get (in, out) is det. 

/* Get the current contents of the mutable object */ 

These operations are implemented using the C-interface of the mercury sy- 
stem: 

pragma ( c_code , mutable__init (Mutable :: out , Value:: in), 
will_not_call_mercury , "{ 

Word *mutable; 
mutable = make (Word); 

(♦mutable) = Value; 

Mutable = (Word) mutable; 

}")• 



:- pragma ( c_code ,mutable__overwrite (Mutable : : in, Value: : in) , 
will_not_call_mercury , "{ 

Word *mutable; 

mutable = (Word *) Mutable; 

MR_trail_current_value (mutable) ; 

(♦mutable) = Value; 

}")• 



:- pragma ( c_code , mutable__get (Mutable :: in. Value: :out), 
will_not_call_mercury , "{ 

Word ♦mutable; 

mutable = (Word ♦) Mutable; 

Value = *mutable ; 

}")• 



Using the mutable object a whole new range of new data structures can be 
used: doubly linked lists, difference lists, .... On creation of a new finite do- 
main variable, the implementation creates a number of slots containing mutable 
objects. 

— A slot for the current domain. 

— Five slots for lists of constraints. Each of those five slots contain constraints 
with a different propagation scheme. The constraints in the first slot are 
only propagated whenever the domain of the variable becomes a singleton, 
the second list of constraints becomes active when the lower-bound of the 
domain changes, the third when the upper bound changes. A fourth list of 
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constraints is activated when the upper bound or the lower bound change^ 
The last list of constraints is propagated whatever change to the domain is 
made. 

— An extra slot can be added containing a string, describing a problem specific 
meaning of the finite domain variable which can be used for debugging or 
output purposes. 

Since the information in those slots will be updated by backtrackable destruc- 
tive assignment, there is need to store these slots in a global data structure. 
When storing them directly as the contents of the finite domain variable, the 
information will be visible and update-able from anywhere in the program at 
constant cost. For storing the constraints in one of these five slots holding con- 
straints a doubly linked list is used. This way new constraints can be added, 
old constraints deleted and constraints retrieved at constant time. The queue of 
constraints maintained by the fixpoint algorithm is a difference list. The only 
way to implement a difference list in the current version of Mercury is using 
backtrackable destructive assignment. This way constraints can be added and 
removed in constant time. An important property is the ability to concatenate 
queues in constant time. Of course special attention has to be paid when using 
these mutable data structures, as bugs in these parts of the program will never 
be found by the compiler. Fortunately the size of the non-declarative code is 
rather small, and the advantage of using Mercury is retained for the remainder 
of the code. 



3.2 Comparison 

A small comparison was made between this new implementation (MROPE II), 
the clp(fd) library from SICStus, the old implementation of ROPE in Prolog 
on top of SICStus, GNU prolog [3| and CHIP, one of the leading commercial 
products in the area having a low-level implementation. 



Table 4. Comparing the solver in Mercury with other systems on a SparcII 



benchmark 


MROPE II 


SICStus 


ROPE(SICStus) 


CHIP 


GNU Prolog 
1.1.2 


queens 8 (all solutions) 


0.12 


0.25 


1.06 


0.08 


0.04 


queens 25 (first solution) 


5.37 


13.45 


45.27 


2.77 


0.80 


bridge 1 


3.35 


1.96 


8.79 


0.82 


0.18 


bridge2 


2.03 


2.19 


4.44 


1.13 


0.30 


suudoku 


0.31 


0.16 


0.2 


0.18 


0.07 



® In previous versions this slot was not available, all constraints to be activated as 
soon as the lower bound or upper bound changed were added twice to the constraint 
store for the variable. Once in the list to be activated when the lower bound changed, 
and once to the list to be activated when the upper bound changed. 
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Five small benchmarks were selected. The classic queens problem, finding 
all solutions for queens(8) and finding the first solution for queens(25). Two 
implementation of the bridge problem the version bridgel backtracks over the 
disjunctions for finding the optimal solution, the version hridge2 first expresses 
the disjunctions connecting a boolean variable to each of the disjunctions. In 
the end the boolean variables are enumerated for finding the optimal solution. 
In principle the last version should be superior, since the disjunctive constraints 
are brought into the constraint store while delaying the choice. These constraints 
can start pruning before they are decided on. The last benchmark is suudoku, a 
Japanese puzzle. 

The benchmarks were performed on both a Solaris machine with a Spar- 
cll processor running at 167 Mhz and a Linux machine having a Pentium II 
233Mhz. On the Solaris machine the SICStus compiler generates “native code”, 
on the Linux machine the SICStus compiler generates “bytecode” , this explains 
the slower execution on the Linux box. From table E]we can see the Mercury im- 
plementation of our solver approaches the timing of the solver 0 delivered with 
SICStus. The Mercury implementation outperforms the Prolog implementation 
ROPE with grace. Our system is still two or three times slower than CHIP, and 
of course does not have the global constraints of CHIP. The results of running 
the same benchmarks on Linux, are shown in Table 0 Here the Mercury im- 
plementation is superior to the SICStus implementation, because the latter one 
is using “bytecode” on Linux. In contrast our system is outperformed by GNU 
Prolog. This shows that compiling the finite domain constraints |H] pays off. Still 
we can see that running the last benchmark (suudoku) on Linux nearly gets to 
the speed of GNU Prolog. In this example some preprocessing is done; during 
that preprocessing we benefit from using Mercury. 



Table 5. Comparing the solver in Mercury with other systems on a Pentium II 



benchmark 


MROPE II 


SICStus 


ROPE(SICStus) 


GNU Prolog 1.0.0 


queens 8 (all solutions) 


0.05 


0.42 


1.79 


0.03 


queens 25 (first solution) 


2.7 


15.7 


78.69 


0.9 


bridgel 


1.57 


2.57 


14.11 


0.12 


bridge2 


0.85 


1.73 


7.79 


0.21 


suudoku 


0.06 


0.18 


0.35 


0.05 
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4 An Example Using MROPE II 

Here an example using the primitives above. It is the implementation of the 
classic queens program. 

Program 2. 

pred queens ( io__state : :di, io__state : :uo) is det . 
queens — > 

io__write_string( "number of queens?"), 

{non_logical_io__read_int (NQ) } , 

({ 

init (Storel) , 

generate (Q, NQ, NQ, Storel, Store2) , 
safeCQ, Store2, StoreS) , 

enumCQ, up, up, standard_ex, StoreS, Store4) , 
non_logical_io__write_string(" [") , 
output_list (Q , Stored), fail 
} -> {true} 

> 

io__write_string("no_solutions") 

). 

pred generate (list (finite_var) , int , int , fd_store, fd_store) . 
mode generate (out , in, in , fd_store_mdi , fd_store_muo) is det. 
generate (Q, N, M) — > 

( |N =0} -> 

{Q = []} 

> 

new_var(X, int(l, M) ) , 

|N1 is N - 1}, 

|Q = [X|Q1]|, 
generate (Ql, Nl, M) 

). 

pred safe (list (finite_var) , fd_store, fd_store) . 
mode safe (in, fd_store_mdi , f d_store jnuo) is semidet . 
safe(Q) — > 

( IQ = []} -> 

{true} 

{Q = [X|T]}, 
noAttack(X, 1,T) , 
saf e (T) 

). 

:-pred noAttack(finite_var, int, list (finite_var) ,fd_store,fd_store) . 
:-mode noAttack(in, in, in, fd_store_mdi,fd_store_muo) is semidet. 
noAttack(X, N, Q) — > 

( {Q = []} -> 
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{true} 



|Q = [Y|Z]|, 

add_constraint (<> (var (X) , +(var(Y), num(N)))), 
add_constraint (<> (var (X) , var(Y))) , 
add_constraint (<> (var (Y) , +(var(X) ,nmn(N)))) , 
|S is N + 1}, 
noAttackCX, S, Z) 



pred output _list (list (finite_var) , fd_store) . 
mode output_list (in, fd_store_mui) . 
output _list (Q , Store) 

( 

Q = [X] , 

value_var(X, [V|_] , Store), 
non_logical_io__write_int (V) , 
non_logical_io__write_string("] ") 



Q = [X, Y|Q1] , 
value_var(X, [V|_] , Store), 
non_logical_io__write_int (V) , 
non_logical_io__write_string(" , ") , 
output_list ( [Y|Q1] , Store) 



5 Contribution 

In this paper we show how a Finite Domain solver written on top of Mercury, 
with very little low-level programming, can be competitive with other well-known 
systems. 

The system is available from 

http://www.cs.kuleuven.ac.be/' henkv/mropellO.l.tar.gz 
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Abstract. We present a framework for Rule Based Programming with 
Constraints and Strategies. It is implemented in the ELAN language, 
that provides an environment for specifying and prototyping deduction 
systems. The existence of strategies provides the user with the possibility 
to make choices, to act upon them, and to retract if needed using back- 
tracking. To illustrate the framework, we formalise a planning problem, 
namely a controller for printing tasks, that shows how to combine rules, 
strategies and constraint solving on finite domains. 



1 Introduction 

Forward chaining rule-based systems (RBS for short) have been widely used in 
artificial intelligence and expert systems. A RBS is basically a set of condition- 
action rules: when the conditions are matched by some facts, the actions are 
performed. This formalism is well-suited for designing supervision applications 
or expressing production rules systems |HR,85l(;R,89j . This programming style 
provides high-level specification, easy prototyping, capability of change, extensi- 
bility and modularity. In connection with RBS, object-oriented approaches have 
been used, for instance in ILOG Rules PM7| . NeOpus EaSH, CLAIRE p:96| 
or Oz |Smo95j. For instance, an ILOG Rules agent is an object that can survey 
other application objects and behave according to them. 

Rule-based programming is also widely used to program constraint solvers, 
especially in Constraint Handling Rules (CHR for short) [Fru92[ . where pro- 
pagation rules are forward chaining rules, combined with simplification rules. 
Considering constraints as syntactic expressions that may be transformed by 
rewriting gives meta-programming capabilities quite useful to eliminate redun- 
dancies or detect inconsistencies in a constraint store. 

Mixing rules and constraints brings other advantages. In classical RBS, it 
is difficult to make use of disjunctive information and to reason about choices. 
A framework called CRP for Constraint Rule-based Programming, has been 
proposed in mm- It extends the basic operational model of RBS to include 
the notion of constraint solving, and uses constraint satisfaction problems to 
model certain types of disjunction. 



K.R. Apt et al. (Eds.): New Trends in Constraints, LNAI 1865, pp. 274-^^^ 2000. 
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Another important idea is to be able to express control in a declarative 
way. For instance, in OPL a modelling language for mathematical pro- 

gramming and combinatorial optimisation problems, problem solving can be 
controlled by a script language that allows programming search procedures and 
specifying how to explore the search space. 

The ELAN system jRKK+96lBKK+^ provides a very general approach to 
rule-based programming. ELAN offers an environment for specifying and pro- 
totyping deduction systems in a language based on rewrite rules controlled by 
strategies. It offers a natural and simple logical framework for the combination 
of computation and deduction paradigms. It supports the design of theorem pro- 
vers, logic programming languages, constraint solvers and decision procedures 
and offers a modular framework for studying their combination. ELAN has a clear 
operational semantics based on rewriting logic |BKKR,9??| . Its implementation in- 
volves compiled matching and reduction techniques integrating associative and 
commutative functions. Non deterministic computations return several results 
whose enumeration is handled thanks to a few constructors of choice strategies. 
A strategy language is available to control rewriting. Evaluation of strategies 
and strategy application is again based on rewriting. Among many applications 
developed in ELAN, the system COLETTE provides various techniques for sol- 
ving constraint satisfaction problems |Ca,s98bj . uniformly based on rewrite rules 
and strategies. 

In this paper we build upon the ELAN system and propose a framework 
providing the concepts of rules, constraints and strategies. 

Our proposition improves ELAN by allowing in the language structured ob- 
jects and constraints into rewrite rules. It improves other systems by adding, 
thanks to strategies, a declarative control on rules. This extension relies on a 
clear semantics since we show in this paper how to map our framework into 
ELAN, providing in this way its interpretation in rewriting logic. 

The proposed framework has the following components: 

— A working memory that is a multiset of structured objects representing the 
current state of the system. Objects may contain constraint variables as 
attribute value, i.e. variables whose possible values are restricted to a specific 
domain. 

~ A set of constrained conditional rules that transform the working memory 
and describe the dynamic aspect of the system. A rule applies if objects 
occurring in the left-hand side match corresponding objects in the working 
memory, and if the conditions specified in the rule are satisfied. Rules may 
involve constraints, i.e. relations between values of attributes in objects oc- 
curring in both sides of the rule. Rules have labels that allow calling them 
in order to control their application through strategies. 

— A constraint store that represents the current constraints in the system. The 
constraint store may be complex and, in that case, it can also be modelled 
as a structured object or as a working memory. Transformations of the con- 
straint store, for instance when a constraint is reduced to a simpler form, 
can also be expressed by rules. 
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Control over rules and constraints is expressed by strategies which allow 
backtracking, choices and search. We use strategies to guide rule application, 
constraint processing and interaction between rules and constraints, such as 
checking satisfiability or enumerating solutions. 

The approach is illustrated by an example, the design of a print controller, 
inspired from [ABC~*~98| . In order to decompose subgoals into simple actions, 
we define a set of constrained rules that generate new subgoals with associated 
constraints. 

In Section 13 we go through the different components of the framework and 
introduce the corresponding language constructions to write programs in this 
framework. We also describe the architecture of the system and the interaction 
between the different components. Section 0 describes the print controller ex- 
ample. In Section El we explain how the framework is implemented in ELAN. 
We define a translation from our programs to ELAN programs, in order to reuse 
the ELAN execution mechanism for program evaluation. This translation has 
the advantage to provide both a logical and operational semantics in rewriting 
logic for our framework. In Section 0, we conclude and propose further research 
directions. 

2 A Framework for Rule-Based Programs with 
Constraints and Strategies 

In order to write programs with structured objects, rules, constraints and stra- 
tegies, we first need a language in which these concepts can be expressed. We 
also have to describe the architecture of the system and how the different com- 
ponents interact. In this section, we present these different components, which 
are the working memory of structured objects (Section ETt . the constraint store 
(Section the constrained rules ISection l^lUl . and the strategies 1 Section lOll . 
Then, we explain the global architecture of the system (Section 12.51 and how 
strategies can be used to control various components and interaction between 
them. 



2.1 The Working Memory of Structured Objects 

Each structured object has a name, a type whose purpose is to classify these 
objects, and a description given by set of pairs (attribute, value). A structured 
object |A^ame : Class :: Attr\ is represented as an expression 

|A^ame : Class :: ai = vi , ... , aNciass ~ '^Ncia.ssl 

where Class identifies the class (or type) of the object named by the identifier 
Name, and (oi = v\, ... , aNciass ~ '^Nciass) i® of pairs (attribute, value) 

that characterises this object. The order of attributes in the list is irrelevant, 
but all objects in a same class have the same number of attributes Nciass- 
We define two kinds of attributes. Constraint attributes are those whose 
values are subject to some constraints related to the modelled problem. The 
value of a constraint attribute is a variable, called a constraint variable, denoting 
values in a specific constraint domain. Unconstrained attributes are the others. 
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Usual operations are provided on all classes of structured objects: 

— to return the value associated to an attribute with the operator where 

denotes a place-holder for argument. For instance, Name.ai returns the 
value Vi associated to the attribute of the object named Name. 

— to modify the value associated to an attribute with the operator ^ _]. 
For instance, associating the value Vi to the attribute of an object Name 
is denoted by Name[ai •<— Vi]. 



Example 1. Let us consider a class Lift defining elevators. Each elevator is a 
structured object composed of three unconstrained attributes: its current floor 
CF, its list of floors LF to be served, and the next floor NF where to go. A 
constraint attribute Zone is added, taking values in a finite domain {1, 2, 3} and 
subject to the constraint that only one elevator may be in each zone at a given 
time. 

An elevator Elevl currently at floor 5, in zone V, with two floors 2 and 9 to 
serve and whose next stop is floor 6 is represented as the following structured 
object: 



\Elevl : Lift :: CF = 5 , LF = 2.9.nil , NF = 6 , Zone = U| 

where U is a constraint variable of finite domain {1,2,3}. The value of V is 
going to be determined by a global constraint on the different elevators. 

Elevl.CF returns the value of the attribute CF. To change the list of current 
floor LF into a new list 1.1 .nil, we write Elevl[LF -(r- 1.7.m/]. 

Each class of objects may also contain additional operations that modify the 
objects (i.e. the values of its attributes), and functions that perform additional 
computations but do not change the objects of the class. The notions of methods 
and messages can easily be taken into account too, but we do not develop this 
extension here. 

The working memory is simply defined as a multiset of structured objects. 

Example 2. For an elevator controller which manages two elevators, we have 
to define two structured objects Elevl and Elev2 of class Lift. The working 
memory is composed by {Elevl, Elev2}. 

Once we have defined the working memory as a multiset of objects, we now 
make precise what are constraints and the constraint store. 

2.2 The Constraint Store 

In order to formalise constraint solving and satisfiability checking, the structure 
of a constraint store may be very complex. It can again be modelled as classes 
of structured objects, where different classes correspond to different kinds of 
constraints. In such cases, to each class should be associated a constraint solver 
and the delicate problem of combining solvers then arise jN()79IHin96IMon99j . 
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For simplicity here, we do not detail the structure of the constraint store, but 
rather consider it as a predefined component that can communicate with ob- 
jects through a given constraint language. Moreover, we restrict ourselves in this 
paper to constraints on finite domains, useful for the kind of applications we 
consider. 

In the constraint language considered here, a constraint c is composed of: 

— a list VarList of membership constraints of the form X D where X is a 
constraint variable and D its associated domain, 

— a set ConsSet of conjunctions and disjunctions of atomic constraints. These 
atomic constraints are either the boolean constraints true or false, or equa- 
lity constraints (ti =■ ^2)1 or ordering constraints (ti >■ t 2 ,ti >■ ^2)1 or their 
negations. Terms involved in atomic constraints are built from constraint va- 
riables and may include in particular arithmetic operators 

We call the pair {VarList , ConsSet) a Constraint Satisfaction Problem (CSP 
for short). 

Example 3. Let us consider three variables V\, V 2 and V3 taking their values in 
the finite domain [0, .., 10] and the following constraint Vi -I- P2 V3 A Vi >■ 
4 A V2 8 A P3 >’ 2. The CSP corresponding to this problem is composed of 
two parts: 

VarList = Vi €' [0, .., 10], P2 S' [0, .., 10], P3 G' [0, .., 10] 

ConsSet = Vi + V 2 =' V3 A Pi A P2 <’ 8 A P3 >' 2 

In this paper, the constraint store is simply a set of Constraint Satisfac- 
tion Problems, which is again a CSP corresponding to the conjunction of the 
constraints in the store. Usual operations are assumed to be available on the 
constraint store, such as getting the list of variables, the current domain of a va- 
riable, checking whether a variable has a unique value in its domain, or whether 
a variable has an empty domain (then the CSP is unsatisfiable), adding a new 
constraint, checking the satisfiability of the CSP, solving a CSP and asking for 
solutions. 

It is now widely admitted to describe a constraint solving process using con- 
straint solving rules that express how to transform a constraint into a solved 
form, or how to simplify a constraint store. This is the approach followed in 
building constraint solvers within CHR jFriiflflj or with rewrite rules in 
where several examples of constraint solvers are given. Solving Constraint Satis- 
faction Problems as defined above can also be formalised using rules as described 
for instance in . We will assume here that the operational semantics of 

the constraint solver and the satisfiability checker is described by constraint 
solving rules. 

In our framework, we consider a constraint solver with the following pro- 
perties: when asking for satisfiability of a constraint, we assume that the con- 
straint solver returns Satisfiable or Unsatisfiable; indeed, in case of an 
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unknown answer, we process it like an Unsatisf iable one. When asking for 
solutions of constraints, we do not assume completeness of the constraint solver. 



2.3 Constrained Rules on the Working Memory 

Changes in the working memory of objects are described through conditional 
rewrite rules with constraints. These rules are of the form: 

[lab] Ox... Ok O'x-.-O'^ [if t | where ^]* || c 

where Oi, . . . , Ofc, Oj, . . . , O'^ are structured objects, t is a boolean term called 
condition, I a local assignment useful to define auxiliary variables, and c is a 
local constraint. This rule can have the label [lab], or no label which is denoted 
[]• 

Rules are applied to the working memory by a rewrite engine that looks for 
candidates in the set of rules. A rule is candidate if its left-hand side matches 
a subset of structured objects in the working memory. Application of this rule 
succeeds only if the tests if t return true and if the local assignments where I 
do not fail. 

The working memory is then updated either by modifying instantiated ob- 
jects occurring in the left-hand side according to their instances in the right-hand 
side: these objects are called modified objects; or by adding instances of new ob- 
jects occurring in the right-hand side but not in the left-hand side: these are 
new objects; or by deleting from the working memory objects occurring in the 
left-hand side but not in the right-hand side: we call them deleted objects; or 
finally by preserving objects appearing both in left-hand side and right-hand 
side and not modified by the rule: these are persistent objects. 

Whenever a rule applies, the local constraint c is added to the constraint 
store. A satisfiability test is not automatically performed when c is added to the 
constraint store. On the contrary, this has to be specified by the user strategies. 
When a fresh local constraint is added to the constraint store, the variables of 
the local constraint are added to the list of variables of the constraint store and 
the new constraint is added to the set of constraints. 

Due to the presence of constraint variables in objects of the working memory, 
we need to precisely define how rules behave in such cases. Let us consider an 
object Oi of class C with a constraint attribute CA occurring in the left-hand 
side of the rule. Given an object |Oi : C :: CA = X] in the left-hand side 
of a rule, the variable X can only be instantiated by a constraint variable V in 
the working memory. After the matching phase, there are two possible tests on 
a constraint variable V : 

— CVEqual{V,v) calls the constraint solver and tests whether the constraint 
variable V can take the value v, by considering the domain of the constraint 
variable and the current constraints on V. 

— CVDef{V) calls the constraint solver and checks whether the constraint 
variable V has a non-empty current domain. 
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The condition must be evaluated to true for applying the rule. If the constraint 
solver fails to answer, the rule is not applied. 

Summarising all conditions that can be tested during a rule evaluation, from 
the global form of a conditional rewrite rule with constraints presented at the 
beginning of this section, we can give a more detailed form of such rules by: 

[lab] 0i...0k^0[...0'^ 

[if t I 

if CV Equal(Vi,v) \ 
if CVDef{V 2 ) I 
where 1]* || c 

Example 4- Let us consider the problem of travelling from one town to another 
within a given time interval D. Assume that we have a map but we only know 
the estimated duration of a few travels between two towns, called elementary 
travels. The problem is to decompose a non-elementary travel into elementary 
ones in order to get an evaluation of the travel duration, within the time interval 
D. 

The class Travel is defined with four attributes: the departure town (attri- 
bute From), the arrival town (attribute To), the departure date (attribute Dep) 
and the arrival date (attribute Arr). The two lasts are constraint attributes. 

The rule below decomposes a non-elementary travel XI in two other travels 
X2 and X3: 

[] I XI : Travel : :Dep=T I => I X2 :Travel : :From=Xl . From To=Town Dep=V(l) Arr=V(2)| 

I X3: Travel : :From=Town To=Xl.To Dep=V(2) Arr=V(3) I 
if CVEqual(T,8) 

if not (ElementaryTraveKXl . From, XI . To) ) 
where Town := () SelectTown(Xl . From.Xl .To) 

II (V(l) in? D, V(2) in? D. V(3) in? D) V(1)>=?X1 .Dep & V(3) <=?X1 . Arr 
end 

When this rule is applied, the structured object A1 is deleted from the wor- 
king memory and replaced by two new objects X2 and A3. 

This rule is selected for any object O of class Travel of the working memory 
matching its left-hand side. The variable T is instantiated to a constraint variable, 
say V, in the constraint attribute Dep of O. The first condition of this rule 
consists of calling the constraint solver to test whether V has the value 8. The 
second condition tests if the travel is not an elementary travel, using the boolean 
operator ElementaryTravel{-, _). If this is the case, the local variable Town is 
instantiated by a new town obtained from an operator SelectTown{-, _), which 
selects on the map one town between the two towns given as arguments. If one 
of the two conditions is not true, the rule is not applied. 

Two new objects of class Travel are created. Their attributes From and To 
can be instantiated, but we do not know the values of the attributes Dep and 
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Arr. We associate to these attributes constraint variables 1^(1), V{2) and F(3) 
that appear also in the local constraint of the rule. 

The local constraint is composed of two parts: the first one defines the do- 
mains associated to each variable (here D) and the second one ensures that the 
departure and arrival dates correspond to the dates required by XI and also 
accepts values that minimise the duration of the travel. This local constraint is 
added to the constraint store if the rule applies. 



2.4 Strategies 

In general, the application of a rule on the working memory may return several 
results, for instance when several objects or multisets of objects match its left- 
hand side. This introduces some non-determinism and the need to control rule 
application. This is why the concept of strategy is introduced. 

A strategy is a function which, when applied to an argument, returns a set of 
possible results. The strategy fails if the set is empty. Relying on our experience 
in ELAN, and in order to provide the user with the capability to easily specify the 
control, we propose a strategy language where the following strategy constructors 
are provided: 

— A labelled rule is a primal strategy. Applying a rule labelled lab returns in 
general a set of results. This primal strategy fails if the set of results is empty. 

~ Two strategies can be concatenated by the symbol i.e. the second stra- 
tegy is applied on all results of the first one. Si; S 2 denotes the sequential 
composition of the two strategies. It fails if either fails or S 2 fails. Its 
results are all results of Si on which S 2 is applied and gives some results. 

~ dk(S'i, . . . , Sn) chooses all strategies given in the list of arguments and for 
each of them returns all its results. This set of results may be empty, in 
which case the strategy fails. 

— first(S'i, . . . , Sn) chooses in the list the first strategy Si that does not fail, 
and returns all its results. This strategy may return more than one result, 
or fails if all sub-strategies Si fail. 

— first_one(S'i, . . . , chooses in the list the first strategy Si that does not 
fail, and returns its first result. This strategy returns at most one result or 
fails if all sub-strategies fail. 

— The strategy id is the identity that does nothing but never fails. 

— fail is the strategy that always fails and never gives any result. 

— repeat* (S') applies repeatedly the strategy S until it fails and returns the 
results of the last unfailing application. This strategy can never fail (zero 
application of S is possible) and may return more than one result. 

— The strategy iterate*(S) is similar to repeat*(S) but returns all intermediate 
results of repeated applications. 

The easiest way to build a strategy is to use the strategy constructors to build 
strategy terms and to define a new constant operator that denotes this (more 
or less complex) strategy expression. This gives rise to a first class of strategies 
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called elementary strategies. Elementary strategies are defined by unlabelled 
rules of the form [] 5" strat, where 5" is a constant strategy operator and 
strat a term built on predefined strategy constructors and rule labels, but that 
does not involve S. The application of a strategy S on a term t is denoted {S) t. 
Recursive and parameterised strategies may also be defined and more examples 
can be found in [fjorf)8| . Examples of strategies are given in Section 0 



2.5 Architecture of the System 

Figure G] represents the components of the framework and the interactions bet- 
ween them. 




Legend: 



Interaction by Strategies 






A 



Interaction by Shared Variables 



Fig. 1. Architecture of the system. 



The first kind of interaction, pictured in the diagram by a dashed arrow, 
between the working memory and the constraint store, is through constraint 
attributes and constraint variables. A constraint variable may appear as the 
value of a constraint attribute of a structured object, and can be used in the 
local constraint of a rewrite rule. 

The second kind of interaction, pictured in the diagram by plained arrows, 
is the control formalised through strategies, used for different purposes: 

— to control the application of rules on the working memory: strategies provide 
the capability to define a sequential application of rules; to make choices 
between several rules that can be applied; to iterate rules; etc. Section I, 8., 8 1 
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presents an example of application where strategies on rules are defined and 
used to explore a search tree. 

— to control the constraint solving process: in particular, specific strategies to 
solve the constraint may be defined. For instance, the constraint solver on 
finite domains used in the application of Section 01 is based on local propa- 
gation techniques and enumeration with backtracking. Strategies give a lot 
of flexibility to design appropriate tactics to solve constraints, to check con- 
sistency or to compute all solutions. This aspect is developed in Section 

— to control the interaction between the rules and the constraint solver or the 
satisfiability checker: this makes possible to choose to perform either a satis- 
fiability test of the constraint, or the generation of one or all solutions, and 
to specify exactly when the solutions are needed. In the following, we assume 
the existence of at least three strategies: Sat to check consistency of a CSP, 
OneSolution to compute the first solution of a CSP and AllSolutions to 
enumerate its solutions. In some cases, it may be needed to provide trans- 
lation mechanisms between the constraint language used in the constrained 
rules and the constraint language used by the solver. 



3 An Example: Design of a Print Controller 

To illustrate the approach, let us consider as an example the design of a print 
controller, inspired from |ABC+fl8^ . 



3.1 The Specification 

The goal of the print controller is to help the user to decompose a complex 
task into a sequence of primitive actions, to determine which sets of actions are 
capable of achieving a given complex print task, and to generate at any step the 
space of possible decompositions, in order to help the user to take decisions. Since 
all print tasks must be achieved before a given deadline, constraints associated 
to this problem are time constraints involving begin and end times of each task. 

A complex task is a structured object of class Task with five attributes giving 
respectively: its name, the number of impressions that the task has to manage, 
the status for the decomposition of this task (either all or split - explained more 
precisely below), a begin time and an end time. 

A primitive action is a structured object of class Action and has three attri- 
butes giving respectively: its name, its begin and end time. 

The problem is to find possible schedules for executing, for instance, on the 
printer, a simple print task and a complex one composed of N print tasks. The 
different possibilities are either to split the complex print task, or to perform 
it in one step before or after the simple print task (this explains the use of the 
attribute status of the class Task). Note that the purpose is not to minimise the 
execution time for these requests, but to find all possible schedules within the 
given deadline. 
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A general view of the problem is represented in Fig. |3 where every decom- 
position of tasks into tasks/actions is represented. These transformations are 
detailed thereafter when we present the associated rules. 




A Task Name 
An Action Name 

Decomposition of a Task into an Action 
Decomposition of a Task into a Task 
Several later decompositions 



Fig. 2. The print controller principle. 



3.2 The Rules 

From this specification, we define six rules to decompose complex tasks into 
other tasks or actions: two for the Main task decomposition, two others for the 
FormPrint task and two last ones for the MultiPrint task. 

The two first rules specify the decomposition of the task Main into a complex 
task FormPrint (FP) to perform later, and a primitive action SimplePrint (SP) of 
duration 2 time units. The two ways to decompose this main task are represented 
by Mainl and Main2 in Fig. El either we decide to execute all the printing jobs 
all together (FormPrint with status All) and to execute the primitive action 
SimplePrint before or after, or we decide to split these printings (FormPrint with 
status Split) and to execute the primitive action SimplePrint when possible. The 
two rules are: 



Rule Based Programming with Constraints and Strategies 285 



[Mainl] |01 : Task Name — Main\ ^ 

|02 : Task :: Name — FormPrint, Status — all, NumI — Ol.NumI — 1, B — V-1, E — V_2| 
|03 : Action :: Name — SimplePrint , B — V-3 , E = V-4\ 

II (V.l G ■ D, V.2 G- D, V.3 G ' D, V.4 G' D) V.2 <■ Ol.E A V.4 <■ Ol.E A 

V.4 =■ y_3(+)2 ((y_l >■ Ol.B A y_3 =■ Ol.B A y_4 =' y_l) V {V.l =’ Ol.B A 

y_3 >■ Ol.B A y_2 =■ V_3)) 



[Main2] |Ol : Task :: Name — Main\ 

|02 : Task :: Name — FormPrint, Status — split, NumI — Ol.NumI — 1, B — V _1, E — V J2\ 
j03 : Action :: Name — SimplePrint , B — V_3 , E = VA\ 

II (y_l G ■ D, v.2 G- D, y_3 G- D, V.4 G' D) V.l >' Ol.B A V.3 >' Ol.B A 
V.2 <■ Ol.E A V.4 <■ Ol.E A V.4 =' V"_3(+)2 A V.3 >' V_1 A V.4 <■ VJ2 



Let US briefly explain these two first rules: a structured object 01 in the left- 
hand side is replaced by structured objects 02 and 03 in the right-hand side. 
Let us consider now the constraints of these two rules. Constraint variables V.l 
to y_4 are put in attributes B and E of objects 02 and 03 and a constraint 
involving these variables is sent to the constraint store. Each variable is initialised 
with a domain D equal to [0, .., T] where T is the end time wanted for the main 
task. The constraints involving begin and end times of the different tasks express 
that SP precedes FP, or FP precedes SP (for FormPrint with status All) and 
that FP begins before SP and ends after SP (for FormPrint with status Split). In 
a more formal way: FP.B =’ SP.E V SP.B =’ EP.E for the first rule labelled 
Mainl and SP.B >’ FP.B A SP.E <p EP.E for the second Main2. 

The two following rules are for decomposing the complex task FormPrint. 
There are two possible choices here: either we do not decompose this task, but we 
load (action Load of duration 1 time unit) the document, multi-print it N times, 
while ensuring that the document is kept in memory during all these operations 
(this is the primitive action FormKeep). The local constraint prevents the SP 
action to happen during this task. This corresponds to the FI decomposition rule. 
Or we decide to decompose the complex task into two parts. The initial number 
N of documents to print is split into N1 and N2 such that iVl -F iV2 = iV. This 
is achieved by the non-deterministic function Split. This corresponds to the F2 
decomposition rule. Moreover, when creating a new FormPrint task, its status 
is given by a non-deterministic choice expressed by the strategy ChooseStatus. 

[FI] |Ol : Task :: Name — FormPrint , Status — all , NumI — AT| 

|02 : Action :: Name — SimplePrint\ =>■ 

|02 : Action :: Name — SimplePrint\ 

|03 : Action :: Name — Load , B — V _1 , E — V-2\ 

j04 : Task :: Name — MultiPrint , NumI = N , B = V_3 , E — VA\ 
j05 : Action :: Name — FormKeep , B — V_5 , E — V_6| 

II {V.l G- D, V.2 G ■ D, V.3 G ' D, V.4 G ' D, V.5 G ' D, V.6 G' D) V.l =' Ol.B A 
V.2 =■ F_l(+)1 A y_3 =■ V.2 A V.4 =■ Ol.E A V_5 =' V.l A V.6 =' V.4 A 
02. B >■ V.4 V 02. E <■ V.l 

[F2] |Ol : Task :: Name — FormPrint , Status — split , NumI — A^| 

|02 : Task :: Name — FormPrint, NumI — Nl, Status — stl, B — VA, E — V-2\ 

|03 : Task :: Name — FormPrint, NumI — N2, Status — st2, B — V-3, E — V-4\ 
where [A/’1,A^2] () split{N) 

where [stl,st2] := () ChooseStatus 

II {V.l G ■ D, V.2 G- D, V.3 G ' D, V.4 G' D) V.l =' Ol.B A V"_3 >' Ol.B A 
V.2 <■ V.3 A Ol.E =■ V.4 
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The two last rules labelled MPl and MP2 decompose the complex task Mul- 
tiPrint. For printing a document N times, it is printed once (the duration of a 
print is 1 time unit) and then — 1 times. 



[MPl] |Ol : Task :: Name — MultiPrint , NumI = 1| 

|02 : Action :: Name — Print , B — V A , E = V-2\ 

II {V.l G- D,V.2 G- D) V.l =■ Ol.B A V.2 =' V_l(+)1 A Ol.B =' V.2 



[MP2] |Ol : Task :: Name — MultiPrint , NumI — N\ ^ 

\02 : Action Name — Print , B — VA , E = V-2\ 

|03 : Task :: Name — MultiPrint , NumI = N — 1 , B — V_3 , E — VA\ 
if TV > 1 

II {V-l G' D, V-2 G ■ D, y_3 G' D, y_4 G ' D) VA =' Ol.B A 
V.2 =■ y_l(+)l A V-2 =■ V-3 A Ol.E =■ y_4 



In the next section, we show how strategies can be used to explore all the 
possibilities and generate all possible schedules. 



3.3 Strategies to Control the Rules 

Three strategies are defined to control the application of the six rules presented 
in the previous section. The first one, Main, tries all possibilities of applying 
Mainl and Main2. Form does the same for the two rules FI and F2. The last one. 
Multi, tries first to apply the rule MPl, and, in case of failure of it, tries the 
second one MP2. 

These three strategies are defined as follows: 

[] Main => dk (Mainl , Main2) 
end 

[] Form => dk (FI , F2) 
end 

[] Multi => first (MPl , MP2) 
end 

Then we may decide to explore the search tree without checking satisfialibity 
of the constraints (for instance for cost reasons) and to enumerate all solutions at 
each node. This is achieved by the strategy Togetherl below. Or we may choose 
to perform a satisfiability test of the constraint store after the application of the 
strategies Main and Form, and another one at the end of each iteration of Multi. 
This is achieved by the strategy Together2 below. 

[] Togetherl => Main;repeat*(Form;repeat*(Multi)) ;AllSolutions 
end 

[] Together2 => Main;Sat;repeat*(Form;Sat) ;repeat*(Multi) ;Sat 
end 
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4 An Implementation in ELAN 

This section describes how the proposed framework has been implemented in 
ELAN. The chosen data structure is explained in Section 14.1 l and the translation 
of constrained rules is detailled in Section E3 The translation of structured ob- 
jects and rules is completely automated, but we do not present in this paper the 
translation of structured objects definition which is similar to the translation of 
object-oriented modules in 0-Maude in jl )Mii8j into system modules in Maude, 
described in [Unr99| . We have reused the constraint solver COLETTE that had 
the advantage to be designed in ELAN too. Its functionalities are recalled in 
Section 14. dl and the strategies to control it are presented in Section 14.41 Then 
we explain the evaluation mechanism of ELAN that allows the execution of the 
translated rules. This is illustrated again with the print controller example. 

4.1 The Data Structures 

Every component of our framework is translated into a term or a rule applying 
on terms. The set of terms 1~{S,X) is defined by a many-sorted signature S 
with a finite set of sorts and of function symbols and a denumerable set X 
of variables. Var{t) is the set of variables occurring in a term t. Constraints, 
constraint satisfaction problems, constraint store, objects, working memory are 
all encoded by terms in specific many-sorted signatures. 

ELAN provides a tuple constructor with a flexible arity, allowing the 

construction of pairs _], 3-tuples _, _], etc. An object |A^ame : Class :: Attr\ 
is represented as a term [N ame, Class ^ Attr] of sort Object, with root operator 
_, _] . The third argument, i.e. the list of attributes, is implemented as a multiset 
of pairs [a^, Vi] where ai is of sort Attribute and Vi of sort Value, natt is a constant 
denoting the empty list of attributes. 

Multisets are built thanks to a binary multiset union operator which is asso- 
ciative and commutative (AC for short), nobj is the identity for multiset union. 
The working memory is thus represented as a multiset of objects, that is a term 
of sort Working Memory with the root operator which has also a 

flexible arity. 

Thanks to the properties of associativity and commutativity of union on 
multisets, the order of (attribute, value) pairs in an object is irrelevant, as well 
as the order of objects in the multiset encoding the working memory. 

The constraint store is also represented as a term of sort ConstraintStore 
corresponding to the CSP presented in Section A CSP is a pair whose first 
component is a list of membership constraints and the second one is a constraint. 
Constraints are themselves implemented as terms on the signature defining the 
constraint language. 

Operators on the constraint store are defined thanks to predefined operations 
on pairs: 

— -VarList returns the list of variables, i.e. the first element of the pair com- 
posing the constraint store. The argument is a constraint store. 
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— -Conset returns the constraint, i.e. the second element of the pair composing 
the constraint store. The argument is also a constraint store. 

— -Max returns the number of variables used in the constraint store. This 
operator is useful to create new variables and to guarantee their unicity. 

— - 1+J -] constructs a new constraint store built from an initial constraint 

store (the first argument) updated with a new CSP composed by a list of new 
variables (the second argument) and a new constraint (the last argument). 

Finally, for encoding the whole framework, we introduce a sort Configura- 
tion and a constructor _with_ for this sort, taking as first argument a term of 
sort Working Memory, and as second argument a term of sort Constraint Store. 

4.2 Constraint Rules 

ELAN provides a very general form of a rule, defined as follows: 

[^] I ^ r where pi := (S\) c\ . . . where := (S'„) c„ 

The terms and set of variables occurring in the rule must satisfy the following 
conditions: 

— I, r,Pi,...,Pn, Cl,..., Cn gT{S,X), 

— Vf, i = 1, . . . ,n. Pi and (Si) Ci have the same sort. 

— 'ii,i = 1, . . . ,n, Var{pi) fl {Var{l) U Var{pi) U • • • U Var(pi_i)) = 0, 

— 'ii,i = 1, . . . ,n, Var{ci) C Var{l) U Var{pi) U • • • U Var(pi-i), 

— Var{r) C Var{l) U Var(pi) U • • • U Var(p„), 

~ Si, . . . ,Sn are strategy terms and (_) _ is the application operator of strate- 
gies on terms. 



The Evaluation Mechanism of an ELAN Rule 

Let us consider a set of rules R that we call a rewrite system. To apply a 
rule [£] I ^ r where p := c of R on a term t (where / and p are two syntactic 
terms), the satisfiability of the condition p := c has to be checked before building 
the reduced term. Let a be the matching substitution from I to (where t^^, is 
the subterm of t at position n). Checking the matching condition p \= c consists 
first of using the rewrite system R to compute a normal form c' of ca, when it 
exists, and then verifying that p matches the ground term c' . If there exists a 
substitution p, such that pp = c' , the composed substitution ap is used to build 
the reduced term t' = t\ rap~\ where 1 1" rcr/r] ^ is the term t which subterm at 
position n is replaced by rap. Otherwise the application of the rule fails. Note 
that for usual boolean conditions of the form if c, p is the identity when the 
normal form of ca is true. It may also happen that no normal form is found for 
ca, in which case the rule is said non-terminating. 
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When the rule is of the form 

[l\ I ^ r where pi := ci . . . where := c„ 

the matching substitution is successively composed with each matching pi from 
Pi to the normal forms of Ciapi . . . /ti-i, for i = 1, . . . , n. If one of these pi does 
not exist, the application of the rule fails. If no normal form is found at some 
step i, the rule does not terminate. 

When the left-hand side of the rule contains AC function symbols, AC mat- 
ching is invoked. The term I is said to AC match another term t if there exists 
a substitution a such that la =ac t- In general, AC matching can return se- 
veral solutions, which introduces a need for backtracking for conditional rules: as 
long as there is a solution to the AC matching problem for which the matching 
condition is not satisfied, another solution has to be extracted. If the pattern p 
contains AC function symbols, a general one-to-one AC matching procedure is 
used pfkefl5j to find a substitution p such that pp. = c' . Only when all soluti- 
ons have been tried unsuccessfully, the application of this conditional rule fails. 
When the rule contains a sequence of matching conditions, failing to find a match 
for the i-th condition causes a backtracking to the previous one. 

The evaluation of a generalised matching condition pi := (Si) Ci involves the 
evaluation of Ci and Si first, and then of the application operator (_)_. In general, 
this leads to a multiset of terms. Finally, the pattern pi is matched with each 
result in this multiset. If either the multiset is empty, or the matching condition is 
not satisfied, then the evaluation backtracks to the previous matching condition; 
otherwise, the evaluation sets a choice point and goes on with one of the returned 
terms. 

Based on this evaluation process, and starting from a query which is a term 
without variables, ELAN builds a derivation tree in which each branch corre- 
sponds to a deduction in rewriting logic. Each node in this tree corresponds to 
a reachable working memory. Since there is no assumption on termination of 
rewrite rules, we may get an infinite derivation tree. 



Translation of Rules 

Let us now explain how the constrained rules presented in Section 1231 are 
translated into ELAN rules. The rule 

[lab] 

[if t I 

if CV Equal{Vi,v) \ 
if CVDef{V 2 ) I 
where 1]* || c 

is transformed into an ELAN rule given in Fig. 0 
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Vars 

Xi,...^Xk : ObjectIdent\ 

X[,...,X'^,Oi,...,Ok ■■ Object, 

Z : Working Memory, 

Ati,...,Atk ■ AttributeList, 

C, Cl : C onstraintStore\ 

61,62 : bool; 

1 [Z;a 6 eZ] {[Xi, CZassi, [ai, ui] . . . , UnJ Ati\}i^[i^...^k] Z with C 

^ X[...X'^ Z with Cl 

2 where Oj := () [X j. Class j, [aj,Vj] . . . [a„^. , v„j] Atj] 

% for the k objects of the original rule 

3 [if t I where /]* 

4 where 61 := {j)CV Equal{ym,v)%for each constraint attribute am,i = [l,..,fc] 

5 if 61 == true 

6 where b 2 ~ {)CV Defiynf) %f or each constraint attribute an^,i = [1, ..,k] 

7 if 62 == true 

8 where X' := () Ocg[i,. 

% for each persistent object 

9 where := () [{a; Wi}ig[i,...,iV 3 ]] 

% for each modified object 

10 where X'^ ■.= {) [0(n), CZass„, {[aji , w; J}i^g[i^,..^jv„] 

{[ 0 * 2 , V-C.Maa: + A^6)]}i2g[i,.,.,jv„],i27^ii 
{[o-l3y-^}heli,..;N„],l3T^ii,l3^l2 natt] 

% for each created object -^c=[m 2 +i,...,m] 

11 where Cl ~ () C [jj [C.VarList,C.ConsSet] 



Fig. 3. Translation of an conditional rewrite rule with constraints. 



Unspecified arguments of AC operators are captured by new variables added 
in the left-hand sides of rewrite rules. Let Z be the variable of sort Working Me- 
mory that captures the other objects of the working memory; let Ati the variable 
capturing the (attribute, value) pairs unspecified in the rule. This corresponds 
to the left-hand side of the rule shown in Fig. 0 line 1. 

In this translation, we decompose the m objects in the right-hand side into 
three sets: 

— persistent objects that are not changed by the original rule. They appear in 
the left-hand side under the form 

^Xi , CloSSi, [tti,r:i] . . . [Uni ; ] Atj] 

and are denoted by new variables X'^ (line 8 ) using local variables Oj (line 

2 ). 

— modified objects that are changed by the rule; they are denoted by new 
variables X'^ (line 9). 
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— new objects that are created by the rule and denoted by new variables X'^ 
(line 10). Each attribute is initialised either by a value given in the rule, 
or by a new variable, used in the constraint store and denoted Vi, or by a 
default value noted _L. 

Lines corresponding to the where statements are reproduced at line 3 as 
lines corresponding to boolean tests t. 

For conditions on constraint variables, we have a transformation that is given 
from line 4 to 7. 

In the last line, the constraint part is translated by updating the constraint 
store thanks to the operator y. 

Example 5. Let us consider the translation of the first rule in the print controller 
example given in Section 13.21 



Vars Ol, 02, 03 : Object I dent', 

V.1,V.2,V.3,VA : Variable- 

[Mainl] |Ol : Task Name — Main\ =>■ 

|02 : Task :: Name — FormPrint, Status — all, NumI — Ol.NumI — 1, B — V-1, E — V_2| 
|03 : Action :: Name — SimplePrint , B — V_3 , E = VA\ 

II {VA G ■ D, VJ2 G- D, VA G ' D, VA G' D) VA <' Ol.E A VA <' Ol.E A 
VA =■ y_3(+)2 ((y_i >■ oi.B A y_3 =■ oi.b a va =■ va) v {va =■ oi.b a 
y_3 >■ OI.B A y_2 =■ y_3)) 



Following the transformation rule given in Fig. 01 we get this ELAN rule with 
the corresponding variable declarations: 

Vars X'2, X'S,Ol : Object 
Xi : Objectident 
LA : AttributeList 
Z : WorkingMemory 
O, Ol : ConstraintStore 

[Mainl] [Xi ,Task, [Name, Main] LA] Z with C ^ X'2 X'Z Z with O' 1 

where Ol () [Xi, Task, [Name, Main] LA] 

where X'2 :— {) [0{2),Task, [Name, FormPrint] [Status, all] 

[NumI , Ol.NumI — 1] [B, V -C.Max + 1] [E, V -C .Max + 2] natt] 
where X^3 ()[0(3), Action, [Name, SimplePrint] [B, V -C.Max + 3] [E, V -C .Max + 4] natt] 

where Cl := ()C l+J [V. C.Max + 1 G ' £>. V. C.Max + 2 G' C, V. C.Max + 3 G ' £>, 

V -C.Max + 4 G ■ £> , V -C.Max + 2 <' Ol.E A V -C.Max + 4 < ' Ol.E A 
V -C.Max + i V -C.Max + ^+)2 A {(V -C .Max + I V OI.B /\ 

V -C.Max + 3 =■ OI.B A V -C.Max + 4=' V -C.Max + 1) V 

(y.C.Maa: + 1 =■ OI.B A V -C.Max + 3 V Ol .B A V.C.Max + 2 =' V.C.Max + 3)) 



4.3 Constraint Solving and Satisfiability Checking: COLETTE 

For solving constraint satisfaction problems, we use the COLETTE system desi- 
gned by C. Castro j( ;a,s98bl( ;a,s98a| and written in ELAN. The COLETTE solver 
is implemented by rewrite rules and uses the same strategy language as the 
one presented in Section 12.41 Despite of this close relationship, we have reu- 
sed COLETTE as a black-box without modifying its code. The constraint store 
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and local constraints in rules are translated in the constraint language accepted 
by COLETTE which transforms them and gives either solutions or satisfiability 
answers. 

Let us briefly recall a few facilities offered by COLETTE for constraint solving 
and consistency checking of CSP. 

COLETTE provides a library of strategies for solving constraint satisfaction 
problems. Several technics and algorithms are used in the CSP community and 
are implemented in the solver. Among them, let us mention the Full Look Ahead 
and the Forward Checking algorithms. In the Full Look Ahead algorithm, once 
a variable is instantiated, the global consistency of the constraint is checked 
before instantiating another variable. The Forward Checking algorithm is a re- 
stricted version of the Full Look Ahead one: each time a variable is instantiated, 
instead of checking the global consistency of the constraint, we only check values 
of variables directly linked with the instantiated variable. Both are implemen- 
ted in COLETTE, as the strategy FCFirstToLastAll for the Forward Checking 
algorithm and as the strategy FLAFirstToLastAll for the Full Look Ahead al- 
gorithm. These two strategies enumerate the values from the smallest value. 
FCLastToFirstAll and FLALastToFirstAll strategies are also defined to enu- 
merate values from the biggest value. 

COLETTE also provides a library of strategies for checking the local or global 
consistency of constraint satisfaction problems. A general technique to check the 
consistency of a constraint is to generate the first solution and, as soon as we 
get it, to return the answer that the CSP is satisflable. In [K ;as98a,| strategies to 
check the consistency of CSPs are also defined and among them we will use the 
LocalConsistencyForEC strategy. 



4.4 Strategies to Control the Constraint Solver 

To define strategies to control the constraint solver, we have adapted the stra- 
tegies Sat, OneSolution and AllSolutions to the language of the solver. 

In this case, we decided that the Sat strategy is the LocalConsistencyForEC 
strategy presented in the previous Section ^31 

The strategy OneSolution is a call to the FCFirstToLastAll strategy in 
order to get its first result with the first one strategy operator. 
AllSolutions strategy is defined with FCFirstToLastAll. 

[] Sat => LocalConsistencyForEC 

end 

[] OneSolution => first one (FCFirstToLastAll) 
end 

[] AllSolutions => FCFirstToLastAll 
end 

These strategies are not the only ones that a user can define and use to 
control the constraint solver. Indeed, we can adapt strategies to the constraint 
solver and to every kind of control that can be handled by the constraint solver. 
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4.5 Prototyping the Print Controller in ELAN 

Coming back to the example of the print controller, let us see how the evaluation 
works. The system is given a query which is a strategy applied to a term that 
represents the initial working memory. The constraint store is initially empty. 
For instance, an input term (a query) is of the form: 

I 0(1) : Task :: Name=Main, Numl=3, B=0, E=6, Status=split I 

where an object 0(1) of class Task with its five attributes instantiated is 
defined in the working memory. 

The construction of the search tree can be done with two execution modes: 
a Full mode and a Step-by-Step mode. 

— The Full mode uses a strategy AllTogether that develops all branches of 
the tree, checking at each node that the constraint is satisfiable. We do 
not compute all solutions, but we check at each node that the constraint 
has at least one solution, so the schedule is feasible. At each leaf, we get a 
possible decomposition for the main task into primitive actions. The strategy 
AllTogether calls the Main, Form and Multi strategies defined above: 

[] AllTogether => Main ; repeat* (Form ; repeat* (Multi) ) ; Sat 
end 

If we test this example with one simple print task and a complex one with 
2 prints and with one simple print task and a complex one with 3 prints, 
we get 3 schedules for the first test and 8 for the second one. We give some 
execution times for those examples: 





For plans 

(No constraint solver call) 


For plans -F schedules 
(With constraint solver calls) 


Example 


Time (in sec.) 


rewriting steps 


Time (in sec.) 


rewriting steps 


1 SP -F 2 FP 


0.080 


2 043 


1.180 


421 043 


1 SP -F 3 FP 


0.640 


17 442 


28.500 


9 766 749 



On a Pentium II, 450 MHz, 128Mo RAM 



Note that the time and the number of rewriting steps increase in the second 
column due to the use of COLETTE as constraint solver. 



— The Step-by-Step mode guides the user during the development of a solution, 
with a menu presented on the screen: 

Could you give us the number associated to the strategy 
you Wcint now to execute (terminated by ’end’)?: 

1- Main 

2- FormPrint 

3- MultiPrint 

4- Satisfiability Test 

5- All Results 

6- One Result 

7- Cut this br Cinch 
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The three first choices help the user to develop the tree and to eliminate 
all complex tasks from the list of tasks. With the fourth choice, we call a 
satisfiability test for the constraint store. The fifth and the sixth ones guide 
the application of the COLETTE strategy: it gives either all results, or only 
the first one. The seventh choice allows the user to cut the current branch 
of the tree, and the exploration starts again at the last set choice point. 

The user choice is guided by the display of the current situation, as shown 
bellow: 

I 0(1. 1.2) : Task :: Status= Bot , E= V(8) , B= V(7) , Numl= 3, Name= MultiPrintI 
I 0(1. 1.3) : Action :: E= V(10) , B= V(9), Name= FormKeepI 
I 0(1. 1.1) : Action E= V(6) , B= V(5) , Name= LoadI 
I 0(1.2) : Action :: E= V(4) , B= V(3) , Name= SimplePrintI 

with 101 I [0, . . ,8] I |V(5)in?[0, . . ,8] .V(6)in?[0, . . ,8] .V(7)in?[0, . . ,8] .V(8)in?[0, . . ,8] . 
V(9)in?[0, . . ,8] .V(10)in?[0, . . ,8] . V(l) in? [0, . . ,8] .V(2)in?[0, . . ,8] .V(3)in?[0, . . ,8] . 
V(4)in?[0, . . ,8] .nill |V(1)>=?0 & V(3)=?0 & V(2)<=?8 & V(4)<=?8 & V(4)=?V(1) & 

V(4)=?V(3) (+)2 & V(5)=?V(1) & V(6)=?V(5) (+)1 & V(7)=?V(6) k V(8)=?V(2) & V(9)=?V(5) 
k V(10)=?V(8) k V(3)>=?V(8) V V(4)<=?V(5) 

As an example, from the query: 

(Step-by-Step) I 0(1) : Task : : Name=Main,NuinI=4,Status=split ,B=0,E=8 | 

one can reach the following result: 

I 0(1. 1.1. 1.2.1) : Action :: E= V(36), B= V(35) , Name= Print I 
I 0(1. 1.1. 1.3) : Action :: E= V(34) , B= V(33) , Name= FormKeepI 
I 0(1. 1.1. 1.1) : Action :: E= V(30) , B= V(29) , Name= LoadI 
I 0(1. 1.1. 2. 2.1) : Action :: E= V(28), B= V(27) , Name= Print I 
I 0(1. 1.1. 2. 3) : Action :: E= V(26) , B= V(25) , Name= FormKeepI 
I 0(1. 1.1. 2.1) : Action :: E= V(22) , B= V(21) , Name= LoadI 

I 0(1. 1.2.2. 1) : Action :: E= V(16) , B= V(15) , Name= Print I 

I 0(1. 1.2. 3) : Action :: E= V(14), B= V(13), Name= FormKeepI 
I 0(1. 1.2.1) : Action :: E= V(10), B= V(9) , Name= LoadI 
I 0(1.2) : Action :: E= V(4) , B= V(3) , Name= SimplePrintI 

where each beginning and ending time of actions are variables that appear 
in the constraint (which is not mentioned here). After solving it, we can have 
the following result where each V{i) is instantiated with a value: 

I 0(1. 1.2.2. 1) : Action :: E= 8, B= 7, Name= Print I 
I 0(1. 1.2. 3) : Action :: E= 8, B= 6, Name= FormKeepI 

I 0(1. 1.2.1) : Action :: E= 7, B= 6, Name= LoadI 

I 0(1. 1.1. 2. 2.1) : Action :: E= 6, B= 5, Name= Print I 
I 0(1. 1.1. 2. 3) : Action :: E= 6, B= 4, Name= FormKeepI 

I 0(1. 1.1. 2.1) : Action :: E= 5, B= 4, Name= LoadI 

I 0(1.2) : Action :: E= 4, B= 2, Name= SimplePrintI 
I 0(1. 1.1. 1.2.1) : Action :: E= 2, B= 1, Name= Print I 
I 0(1. 1.1. 1.3) : Action :: E= 2, B= 0, Name= FormKeepI 

I 0(1. 1.1. 1.1) : Action :: E= 1, B= 0, Name= LoadI 

This schedule proposes to execute the simple print task SimplePrint between 
time 2 and 4. The complex print task is decomposed into three ones that are 
executed for the first one between 0 and 2 (Load between 0 and 1 - Print 
between 1 and 2 - FormKeep between 0 and 2), for the second one between 
4 and 6 (Load between 4 and 5 - Print between 5 and 6 - FormKeep between 
4 and 6) and for the last one between 6 and 8 (Load between 6 and 7 - Print 
between 7 and 8 - FormKeep between 6 and 8). 
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5 Conclusion 

This work contributes to supporting the extensible use of strategies in constraint 
solvers and deduction with constraints. The concepts of rules, constraints and 
strategies have already been used in many other works, and some of them have 
already been mentioned in the introduction. The originality of our approach 
based on ELAN is really to combine these features in a uniform framework with 
logical foundations. 

Being backed upon a simple logic like rewriting is a main advantage for de- 
signing safe applications. Several works have already been done on Production 
Rule Systems to verify such systems and to prove their confluence or termina- 
tion. We can mention here the COVADIS system pi,oii88| designed to prove the 
consistency of knowledge-based systems. PREPARE [ZN94j is also a system able 
to detect potential errors of rule-based systems. In jsnsi, Schmolze and Snyder 
have also defined a tool based on the Knuth-Bendix Completion |KB7flj to test 
the confluence of Production Rules Systems. In order to prove termination of 
constraint solver implemented in CHR, Friiwirth has adapted technics usually 
used in rule-based systems IFriiOO). However a challenging question is now to 
extend these proof techniques to take into account strategies. Indeed a set of 
rules may be non confluent or non terminating in general but confluent and 
terminating under a given strategy. 

Since structured objects already belong to this framework, it may be worth 
adding also concepts like methods and messages from object programming in 
this environment. The proposed framework allows us to express concurrency 
and synchronisation between structured objects. Since we allow several objects 
in the left-hand sides of rules, this means that in order to apply the rule, these 
objects need to match objects simultaneously present in the working memory. 
More examples need to be studied to illustrate this capability. 
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Abstract. We adapt and extend existing approaches to termination in 
rule-based languages (logic programming and rewriting systems) to prove 
termination of actually implemented CHR constraint solvers. 

CHR (Constraint Handling Rules) are a declarative language especially 
designed for writing constraint solvers. CHR are a concurrent constraint 
logic programming language consisting of multi-headed guarded rules 
that rewrite constraints into simpler ones until they are solved. 

The approach allows to prove termination of many constraint solvers, 
from Boolean and arithmetic to terminological and path-consistent con- 
straints. Because of multi-heads, our termination orders must consider 
conjunctions, while atomic formulas suffice in usual approaches. 

Our results indicate that in practice, proving termination for concurrent 
constraint logic programs may not be harder than for other classes of 
logic programming languages, contrary to what has been feared in the 
literature. 



1 Introduction 

We adapt and extend existing approaches to termination in rule-based langua- 
ges (logic programming and rewriting systems) to prove termination of actually 
implemented CHR constraint solver programs. 

CHR (Constraint handling rules) lh'ru98IAh'M99l are a high-level language 
especially designed for writing constraint solvers. CHR are a committed-choice 
concurrent constraint logic programming language consisting of multi-headed 
guarded rules that rewrite constraints into simpler ones until they are solved. 
CHR define both simplification of and propagation over user-defined constraints. 
Simplification replaces constraints by simpler constraints while preserving logi- 
cal equivalence. Propagation adds new constraints which are logically redundant 
but may cause further simplification. CHR have been used in dozens of projects 
worldwide to encode constraint solvers, including new domains such as termi- 
nological, spatial and temporal reasoning jFrii98j and new applications domains 
such as optimal placement of sender stations [IFrHrOOj . 

The study of termination of CHR programs is not only essential for reliable 
constraint solvers, termination is a prerequisite for analyzing and deciding con- 
fluence jA bd97IA FM99| and operational equivalence |AbFr99j of CHR programs. 



K.R. Apt et al. (Eds.): New Trends in Constraints, LNAI 1865, pp. 298-^^3 2000. 
@ Springer- Verlag Berlin Heidelberg 2000 
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Confluence guarantees that the result of a computation will always be the same, 
no matter which of the applicable rules are applied. 

In logic programming in general, a termination problem can only occur if 
recursion is involved. Once recursion is present, the problem is almost at once 
undecidable. There is a fair amount of work on sufficient conditions ensuring 
termination of (pure) logic programs jdSn94j . which started about a decade 
ago. The basic idea is to prove that in each rule, the head atom is strictly larger 
than every atom occurring in the body of the rule. 

Typically, the necessary well-founded orders are adopted from term rewriting 
systems (TRS). A commonly used order is called polynomial interpretation which 
is known in TRS since more than twenty years |Der87IBaNi98| . The idea is 
to map terms and atoms to natural numbers. Instances of this mapping are 
also called measure function, norm, ranking or level mapping. To ensure well- 
foundedness, programs and queries usually have to be well-moded (and well- 
typed) or queries sufficiently known. 

The main line of work in termination of logic programs is considered to be 
from Apt, Bezem and Pedreschi |ADPe9( |Bez98l . Both programs and goals are 
characterized in terms of level mappings, a function from ground atoms to natural 
numbers. A logic program is recurrent if for every ground instance of each rule, 
the level of the head atom is higher than the level of each body atom. A goal is 
hounded (rigid) if for every (ground) instance of each atom in the goal there is a 
maximum level which is not exceeded. Successive work of the authors refined this 
approach: Local variables and the specific left-to-right SLD resolution of Prolog 
are taken into account. A program is acceptable if for every ground instance of 
each rule the level of the head atom is higher than the level of each body atom 
whenever it is not in the model of the program and all the body atoms on the 
right are in the model. The model of a program is characterized by suitable 
interargument relations that must hold on the atoms. The notion of bounded 
goals is extended as well to take the model into account. 

There are only a few recent papers on termination for constraint logic pro- 
grams |( IM M 95IMes9fi^Rug97| , logic programs with coroutining |JNai92IMa'Te95| 
and concurrent logic programs IPIufl:^IKKSflVI . m,ug9VIMes9BlMa,Te95lPlu92l 
embark on level mappings. The theoretical work provides necessary 

and sufficient conditions for termination based on dataflow graphs, the practical 
work |JNaiH2| discusses informally how terminating procedures can be combined 
ensuring overall termination, and can use techniques from TRS directly 

since they translate GHC programs into TRS. 

To the best of our knowledge, there is no work yet on proving termination of 
concurrent constraint logic programs and of constraint solver implementations. 

In the literature it is generally agreed that the issue of termination for con- 
current constraint languages is even harder than for other logic programs, since 
programs with constraints do not go well with the idea of modes and well- 
modedness, and since programs with coroutining or concurrency do not have a 
statically fixed search and selection rule. 
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The following example illustrates the behavior of committed-choice languages 
with respect to delaying and termination. 

Example 1. Consider a CHR constraint characterizing even numbers. We use 
Prolog syntax, where Variables start with upper case letters, and function and 
predicate symbols with lower case letters. Assume that numbers are expressed 
in successor notation and that = means syntactical equality. The constraint may 
be defined by the single rule: 

even(X) <=> X=s(Y) I Y=s(Z), even(Z) . 

The rule says that if the argument X to even is the successor of some number 
Y, then the predecessor of this number Z must be even in order to ensure that 
the initial number X is even. The query even(N) delays. The query even(f (N)) 
delays as well. To the query even(s(N)) the rule is applicable, the answer is 
N=s(Nl), even(Nl). 

It was already discussed in detail in |N^ that the conjunction of two 
query atoms, that both terminate on its own, need not terminate. Here, the 
query even(N) , even(s(N)) will not terminate. It leads to even (N) , N=s(Nl), 
even(Nl), which is equivalent to even(s(Nl) ) , even(Nl), which is just a vari- 
ant of the initial query. 

For CHR, we not only have concurrency and constraints, but also propagation 
rules and multiple heads to consider. Thus we cannot hope to give a definitive 
or final answer concerning termination at this point in time. In this paper we 
rather concentrate on ensuring termination in practice, in existing constraint 
solvers written in CHR. 

Overview of the Paper. We will first give syntax and semantics for CHR. 
In the next section, we introduce useful termination orders for CHR. Then we 
prove termination of actually implemented CHR constraint solvers ranging from 
Boolean and arithmetic to terminological and path-consistent constraints. Fi- 
nally, we summarize the achievements of the current approach and discuss future 
work. 



2 Syntax and Semantics 



In this section we give syntax and simple semantics for CHR, for more detailed 
semantics see [Abd971AFM99| . We assume some familiarity with (concurrent) 
constraint (logic) programming jvHSn921,T a,M a94IFr A h97IM a,St98l( ID.TK 99] . 

A constraint is a predicate (atomic formula) in first-order logic. We distin- 
guish between huilt-in (predefined) constraints and CHR (user-defined) con- 
straints. Built-in constraints are those handled by a predefined, given constraint 
solver. CHR constraints are those defined by a CHR program. 

The syntax of CHR is defined by EBNF grammar rules and is reminiscent of 
Prolog and GHC. Upper case letters stand for conjunctions of constraints. 
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Definition 1. A CHR program is a finite set of CHR. There are two kinds of 
CHR. A simplification CHR is of the form 

[N H ’<=>’ [G ’ I ’] B. 

and a propaggation CHR is of the form 

[N H ’==>’ [G ’ I ’] B. 

where the rule has an optional name N, the multi-head H is a conjunction of CHR 
constraints. The optional guard G is a conjunction of built-in constraints. The 
body B is a conjunction of built-in and CHR constraints. As in Prolog syntax, a 
conjunction is a sequence of conjuncts separated by commas. 

The declarative semantics of a CHR program P is a conjunction of univer- 
sally quantified logical formulas (one for each rule) and a consistent built-in 
constraint theory CT which determines the meaning of the built-in constraints 
appearing in the program. The theory CT is expected to include an syntac- 
tical equality constraint = and the basic trivial constraints true and false. The 
declarative reading of a rule relates heads and body provided the guard is true. 
A simplification rule means that the heads are true if and only if the body is 
true. A propagation rule means that the body is true if the heads are true. 

The operational semantics of CHR programs is given by a state transition 
system. With computation steps (transitions, reductions) one can proceed from 
one state to the next. A computation is a sequence of computation steps. 

Definition 2. A state (or: goal) is a conjunction of built-in and CHR con- 
straints. An initial state (or: query) is an arbitrary state. In a final state (or: 
answer) either the built-in constraints are inconsistent or no computation step 
is possible anymore. 



Definition 3. Let P be a CHR program for the CHR constraints and CT be 
a constraint theory for the built-in constraints. The transition relation i — > for 
CHR is as follows. All variables occurring in states stand for conjunctions of 
constraints, x denotes the variables occurring in the rule chosen from P. 

Simplify 

P' A P I — > {H = H') AG AB AD 

if {H <=> G I P) in P and CT \= D 3x{H = H' AG) 

Propagate 

P' A P I — > {H = H') AG AB AH' AD 

if (P ==> G I P) in P and CT D ^ 3x{H = H' AG) 

By equating two atomic constraints, c(ti, . . . , f„) = c(si, . . . , s„) syntactically, 
we mean (p = si)A. . .A(t„ = s„). By (Pi A. . .AP„) = (P(A. . .AP(,) we mean 
(Pi = P() A ... A (P„ = P(j). Conjuncts can be permuted since conjunction is 
assumed to be associative and commutative. 
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When we use a rule from the program, we will rename its variables using new 
symbols. A rule is applicable to CHR constraints H' whenever these atomic 
constraints match (are an instance of) the head atoms H of the rule and the 
guard G is entailed (implied) by the built-in constraint store. The matching is 
the effect of the existential quantification in 3x{H = H') |Mah87| . Matching 
and entailment checks are performed by the constraint solver for the built-in 
constraints. Any of the applicable rules can be applied, but it is a committed 
choice, it cannot be undone. 

If an applicable simplification rule {H <=> G I R) is applied to the CHR 
constraints H' , the Simplify transition removes H' from the state, adds B and 
also adds the equation H = H' and the guard G to the state. If a propagation 
rule {H ==> G I R) is applied to H' , the Propagate transition adds B and 
also adds the equation H = H' and the guard G, but does not remove H' . 
Trivial non-termination is avoided by applying a propagation rule at most once 
to the same constraints. A more complex operational semantics that addresses 
these issues can be found in i™?! . Details on how to efficiently implement 
the operational semantics given here can be found in poFr00| . The examples in 
Section E] will help to clarify the operational semantics. 



3 CHR Termination Orders 



To prove termination of CHR computations, we rely on polynomial interpretati- 
ons, where the rank of a term or atom is defined by a linear positive combination 
of the rankings of its arguments. In the following we define a scheme for a class of 
rankings that we will use in the sequel to prove termination of constraint solvers 
written in CHR. The basic definitions follow 






Definition 4. Let / be a function or predicate symbol of arity n (n > 0). A 
CHR ranking (function) defines the rank of a term or atom /(ti,...,f„) as a 
natural number: 



rank{f{ti, . . . ,tn)) = + a{ * rankifi) + . . . + * rankifn) 

where the a{ are natural numbers. For each variable X we impose rank{X) > 0. 

This definition implies that rank{t) > 0 for all rankings in our scheme and for 
all terms and atoms t. 

Instances of the ranking scheme rank specify the function and predicate 
symbols and the values of the coefficients a{ . 



Example 2. The size of a term can be expressed in this scheme by: 
size{f{ti, . . . , tn)) = 1-1- size{ti) size{tn) 



For example, the size of the term f (a,g(b,c)) is 5. The size of f (a,X) is 2 -|- 
size{X) with rank(X) > 0 when no additional constraints are introduced for 
ranks of variables. This allows us to conclude that the term f (g(X) ,X) is larger 
in size than f (a,X) (2 -|- 2 * size{X) > 2 + size(X)), no matter what term X 
stands for. 
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An expression rank{s) © rank(t) is called an order constraint, where 0 G {< 
, <, =, >, >}. To avoid clutter, we also write s >- t for rank(s) > rank{t). The 

notion of order constraints will be used to formalize interargument relations, i.e. 
relations between the ranks of arguments of constraints that are needed to prove 
termination. 

Two important properties of termination orders are well-foundedness and 
stability. 

Definition 5 . An order is well-founded if there are no infinite decreasing chains 
ri, . . . , r„ . . . such that for all i > 1. 

Definition 6. An order © has the stability property if it is closed under substi- 
tutions: 

s © t — >■ cr(s) © a{t) for all terms s and t and for all substitutions a, 

where t contains only variables that also appear in s. 

Linear polynomial orders (definable by our ranking function scheme) are 
known to be well-founded and closed under substitutions |fjalNif)8| . 

Induced Orders on Sequences and Multi-sets 

If a ranking does not suffice to prove termination, it can be used to induce an 
order on sequences of finite length (tuples) and multi-sets EEHZI. In this paper, 
for one constraint solver we have to rely on multi-sets to prove its termination 

(see Section E 3 - 

Definition 7 . The lexicographic order on sequences is defined by: 

(si,...,Sti) I {t\, . . . ,trri) 

iff there exists i with (1 < f < n) such that Sj >- ti or i > m and for all j with 
(1 < j < i) it holds that Sj = tj. 

If the sequences have different size, this only matters if the shorter sequence is 
a prefix of the longer one. In that case, the longer sequence is larger. 

Definition 8. The multi-set order on multi-sets is defined by: 

iff there exist i G { 1 , . . . , n} and 1 < < . . . < jfe < to with 0 < k such that Si >- 

tj ^, . . . , Sj © ^^d S ^ jYi T or S ytl ^ where S • ■ • ? • 7 

and T — ^t\ , . . . , tj^'^ {Iji 7 ■ • ■ 7 }■ 

In words: The smaller multi-set is obtained from the larger one by removing a 
nonempty subset and adding only elements which are smaller than some element 
in the subset. Or: Every element in the smaller multi-set must be smaller or equal 
than one in the larger multi-set, and there must be at least one element that is 
strictly smaller. Even though the definition is contrived, there is a simple way 
to compare multi-sets for total orders: Sort the multi-sets into descending order 
and compare the resulting sequences lexicographically. 
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Sequences and multi-set orders induced by linear polynomial orders are also 
well-founded and closed under substitutions EiMI. When such induced or- 
ders are used, the ranking function has to be lifted accordingly by introducing 
auxiliary functions that yield sequences and multi-sets respectively from ranks 
(see Section O for an example). 

4 Proving Termination of Constraint Solvers 

We are interested in termination of actually implemented CHR constraint solver 
programs. We want to prove termination under any scheduling of rule applica- 
tions (independent from the search and selection rule). We also want to make 
sure that a conjunction of terminating queries is itself a terminating query. This 
means that we embark on a rather strict notion of termination. 

Definition 9. A CHR program P is called terminating for a class of queries, if 
there are no infinite sequences of computation steps using rules from P starting 
from a query in the class. 

Roughly, a CHR program can be proved to terminate if we can prove that in 
each rule, the rank of the head is strictly larger than the rank of the body. 

A ranking for a CHR program will have to define the ranks of CHR and 
built-in constraints. In extension of usual approaches, we also have to define the 
rank of a conjunction of constraints, since CHR are multi-headed. We will define 
the rank of any built-in constraint to be the smallest element in the order (i.e. 0 
or {} for multi-sets), since we assume that they always terminate. The rank of a 
conjunction should reflect that conjunctions of CHR constraints are associative 
and commutative, but not idempotent. Thus obvious choices are -I-, and U for 
multi-sets, repectively. 

A built-in constraint may imply order constraints between the ranks of its 
arguments (interargument relations), e.g. s=t — >■ rank{s) = rank{t). We assume 
these order constraints are given and known to be correct. 

In this paper, we formalize a termination condition for simplification rules. 
We currently cannot deal with propagation rules in their generality, rather we 
will deal with them in a solver-dependent way. 

Definition 10. The ranking condition of a simplification rule H <=> G I B is 
the formula 

V {RC{G,B) 

where RC(G,B) is a conjunction of order constraints implied by the built-in 
constraints in the guard and body of the rule. 

Since rankings are based on linear polynomial orders, H >- B does not univer- 
sally hold if B contains local variables not occurring in H, except if the order 
constraints RC{G,B) imply an appropriate relationship between the variables. 

The intuition behind the definition of a ranking condition is that the built-in 
constraints in the rule will imply order constraints RG{G,B) that can help us 
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to establish that H >- B. There is no need in RC{G, B) to distinguish between 
built-in constraints from the guard and from the body, even though they avoid 
non-termination for different reasons: If the constraints in the guard do not 
hold, the rule is not applicable, and neither is any instance of it. If the built- 
in constraints in the body do not hold, the application of the rule leads to an 
inconsistent, thus hnal state. 

To prove termination, goals have to be sufficiently known. 

Definition 11. A goal A is bounded if the rank of any instance of A is bounded 
from above by a constant k. 

Obviously, the rank of a ground (variable-free) term is always bounded. Intui- 
tively, in bounded goals, variables only appear in positions which are ignored 
by the ranking. The use of well-modedness instead of boundedness is not hel- 
pful in programs that define constraints, which should allow for arbitrary modes 
by definition, see Example 1. Obviously, boundedness generalizes the notion of 
modes. 

The following two analogous theorems tell us how to prove CHR termination. 



Theorem 1. Given a CHR program P without propagation rules and a ranking 
where 

rank{{A A B)) = rank{A) + rank{B) 

for any two goals A and B. If the ranking condition holds for each rule in P, 
then P is terminating for all bounded goals. 

Proof. Consider a state H' A D. Applying the rule {H <=> G \ B) will lead 
to the state {H = H') A G A B A D. 

We have to show that rank{H' AD) > rank{{H = H') AG AB AD) and that 
the ranks of all states in a computation are bounded. 

We know that rank{G) = 0, rank{H = H') = 0, since 0 is the smallest 
element in our polynomial order, and that {H = PI') -A rank{Pl) = rank{Pl'). 
Since RG{G,B) -a rank{P[) > rank{B), we have that 

rank{P[' A D) = rank{Pl') + rank{D) = rank{P[) + rank{D) > 

0 -I- 0 -I- rank{B) + rank{D) = rank({{H = P[') AG AB A D)). 

To show that the ranks of all states are bounded, note the following: Any ranking 
is well-founded and has the stability property. Since goals are bounded, the rank 
of a state is bounded. Due to the ranking condition, the boundedness of the 
source state is propagated to target state, i.e. given a bounded state H' A D, the 
application of any simplification rule will lead to a state that is bounded again. 
Thus no infinite computations are possible, hence P is terminating. 

The second Theorem is analogous to the first one, except that we consider 
multi-set orders. 
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Theorem 2. Given a CHR program P without propagation rules and a multi- 
set order defined by a function mrank which is induced by a polynomial ranking 
rank, and such that 

mrank((A A B)) = mrank(A) U mrank(B), 

where A and B are goals and U denotes multi-set union. If the ranking condition 
holds for each rule in P, then P is terminating for all bounded goals. 

Proof. Consider a state H' A D. Applying the rule {H <=> G \ B) will lead 
to the state {H — H') A G A B A D. 

We have to show that mrank{H' A D) D mrank{{H = P[') AG A B A D) and 
that the ranks of all states in a computation are bounded. 

We know that mrank{G) = {}, mrank{Pl = H') = {}, since {} is the smallest 
element in the multi-set order, and that {PI = PI') -A mrank{H) = mrank{Pl'). 
Since RG{G,B) -a mrank{P[) D mrank{B), we have that 

mrank{H' A D) = mrank{Pl') U mrank{D) = mrank{Pl) U mrank{D) D 
{} U {} U mrank{B) U mrank{D) = mrank{{{H = H') AG A B A D)). 

To show that the ranks of all states are bounded, note the following: Any multi- 
set order induced by a polynomial ranking is well-founded and has the stability 
property. Since goals are bounded, the rank of a goal is bounded. Since there is 
only a finite number of goals in a state, the multi-set of its ranks is finite. Due 
to the ranking condition, the boundedness of the source state is propagated to 
target state. Thus no infinite computations are possible, hence P is terminating. 

We are now ready to prove termination of actually implemented CHR con- 
straint solvers ranging from Boolean and arithmetic to terminological and path- 
consistent constraints. For details on the constraint solvers analyzed here see 
and the CHR web pages: 

www.pst . inf ormatik.uni-muenchen. de/^fruehwir/chr-intro .html 
4.1 Boolean Algebra, Propositional Logic 

The domain of Boolean constraints includes the constants 0 for falsity, 1 for 
truth and the usual logical connectives of propositional logic, e.g. and, or, 
neg, imp, exor, modeled here as relations. Syntactical equality = is a built-in 
constraint. As a first, simple, but nevertheless useful example for a constraint 
solver, we can define an auid constraint using value propagation, a special case 
of arc consistency: 



and(X,Y,Z) 


<=> X=0 


1 Z=0. 


and(X,Y,Z) 


<=> Y=0 


1 Z=0. 


and(X,Y,Z) 


<=> X=1 


1 Y=Z. 


and(X,Y,Z) 


<=> Y=1 


1 X=Z. 


and(X,Y,Z) 


<=> Z=1 


1 X=1,Y=1 


and(X,Y,Z) 


<=> X=Y 


1 Y=Z. 
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For example, the first rule says that the constraint and (X , Y , Z) , when it is known 
that the first input argument X is 0, can be reduced to asserting that the output 
Z must be 0. Hence the query and(X,Y,Z) ,X=0 will result in X=0, Z=0. 

The above rules terminate, since the CHR constraints aind is not recursive. 
Any ranking that maps and to a positive number suffices to show this. The same 
holds for the other connectives. 

In general, in termination proofs we can ignore rules whose body contains 
only built-in constraints. 

A constraint solver is complete if can always reduce inconsistent CHR con- 
straints to false. To achieve completeness for Boolean constraints as defined 
here, search must be employed by trying out values for the variables. In gene- 
ral, one is happy with incomplete solvers, because they have polynomial time- 
complexity as opposed to the exponential complexity of complete algorithms. 
Completeness has nothing to do with termination, but is mentioned in this pa- 
per to characterize the constraint solvers. 

Boolean Cardinality 

The cardinality constraint combinator was introduced in the CLP language 
cc(FD) [yHSUDZ] for finite domains. We adapted it for Boolean variables. The 
Boolean cardinality constraint #(L,U,BL,N) holds if between L and U Boolean 
variables in the list BL are equal to 1. N is the length of the list BL. Boolean cardi- 
nality can express e.g. negation #(0,0, [C] ,1), exclusive or #(1,1, [C1,C2] ,2), 
conjunction #(N,N, [Cl, . . . ,Cn] ,N), and disjunction #(1,N, [Cl, . . . ,Cn] ,N). 
In the following code, all constraints except cardinality # are built-in. 

7o trivial, positive and negative satisfaction 
triv_sat@ #(L,U,BL,N) <=> L=<0,N=<U I true. 
pos_sat a #(L,U,BL,N) <=> L=N I all(l,BL). 

neg_sat @ #(L,U,BL,N) <=> U=0 I all(0,BL). 

7o positive Etnd negative reduction 

pos_red Q #(L,U,BL,N) <=> deleted, BL,BL1) I 0<U,#(L-1,U-1,BL1,N-1) . 
neg_red Q #(L,U,BL,N) <=> delete(0,BL,BLl) I L<N,#(L,U,BL1 ,N-1) . 

all(T,L) binds all elements of the list L to T. delete(X,L,Ll) deletes the 
element X from the list L resulting in the list LI. When delete/3 is used in the 
guard, it will only succeed if the element to be removed actually occurs in the 
list. E.g. deleted, BL,BL1) will delay if it tries to bind a variable in BL to 1. It 

will only succeed if there actually is a 1 in the list. It will fail, if all elements of 

the list are zeros. 

Termination. The rules are still simple (single-headed simplification rules), 
but some are recursive. Since the cardinality constraint is either simplified into a 
built-in constraint (satisfaction rules) or reduced to a cardinality with a shorter 
list (reduction rules), this implementation terminates. 

More formally, our termination proof is based on the length of the list: 

ranfc(#(L, U, BL, N)) = length{BL) 
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The length of a list can be expressed in our ranking scheme by: 
length (W) = 0 

length ([X\L]) = 1 + length{L) 

For example, the length of [a,b,c,d] is 4, the length of [a|L] is 1 + length{L) 
with length{L) > 0. 

Remember that the rank of built-in constraints is always 0, but that they 
may imply order constraints. This is the case for delete/3: 

delete{X, LI) — >■ length{L) = length(Ll) -|- 1 

Finally, the rank of a conjunction is the sum of the ranks of its conjuncts: 

rank{{A A B)) = rank{A) + rank{B) 

The interesting case for termination are the two reduction rules, because they 
are recursive. From the rule 

pos_red 0 #(L,U,BL,N) <=> deleted, BL.BLl) I 0<U,#(L-1,U-1,BL1,N-1) . 
we get to prove 

length{BL) = length{B LI) -|- 1 — >■ length{BL) > length{BLl). 

The ranking condition holds, and in the same way we prove termination for the 
neg_red rule. 

Due to the ranking, a goal consisting of built-in and cardinality constraints 
is bounded if the lengths of the lists in the cardinality constraints are known, i.e. 
if the lists are closed. If a list was open(-ended), there could be producers of an 
infinite list, and then the associated cardinality constraint would not necessarily 
terminate. 



4.2 Terminological Reasoning 

Terminological formalisms (aka description logics) |HaHa,^ l) are used to repre- 
sent the terminological knowledge of a particular problem domain on an abstract 
logical level. To describe this kind of knowledge, one starts with atomic concepts 
and roles, and then defines new concepts and their relationship in terms of exi- 
sting concepts and roles. Concepts can be considered as unary relations similar 
to types. Roles correspond to binary relations over objects. Although there is 
an established notation for terminologies, we use a more verbose syntax to help 
readers not familiar with the formalism. 

Definition 12. Concept terms are defined inductively: Every concept (name) c 
is a concept term. If s and t are concept terms and r is a role (name), then the 
following expressions are also concept terms: 

s cind t (conjunction), s or t (disjunction), nota s (complement), 
every r is s (value restriction), some r is s (exists-in restriction). 
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Objects are constants or variables. Let a, b be objects. Then a : s is a membership 
assertion and (a, 6) : r is a role-filler assertion. An A-box is a conjunction of 
membership and role-filler assertions. 



Definition 13. A terminology (T-box) consists of a finite set of concept defini- 
tions 

c isa s, 

where c is a newly introduced concept name and s is a concept term. 

Since the concept c is new, it cannot be defined in terms of itself, i.e. concept 
definitions are acyclic (non-recursive). This also implies that there are concepts 
without definition, they are called primitive. 

The CHR constraint solver for terminologies encodes the T-box by rules and 
the A-box as CHR constraints, since we want to solve problems over a given 
terminology (T-box). A similar solver is described in |FrHa95j . 

The consistency test of A-boxes simplifies and propagates the assertions in 
the A-box to make the knowledge more explicit and looks for obvious contradic- 
tions (“clashes”) such as X : device, X : nota device. This is expressed by 
the rule: 

I : nota S, I : S <=> false. 

The following simplification CHR show how the complement operator nota can 
be pushed towards to the leaves of a concept term: 

I : nota nota S <=> I : S. 

I : nota (S or T) <=> I : nota S and nota T. 

I : nota (S and T) <=> I : (nota S or nota T) . 

I : nota (every R is S) <=> I : some R is nota S. 

I : nota some R is S <=> I : every R is nota S. 

An exists-in restriction generates a new variable that serves as a “witness” for 
the restriction: 

I : some R is S <=> (I,J) : R, J : S. 

A value restriction has to be propagated to all role fillers: 

I : every R is S, (I,J) : R ==> J : S. 

The unfolding rules replace concept names by their definitions. For each concept 
definition C isa S two rules are introduced: 

I : C <=> I : S. 

I : nota C <=> I : nota S. 

The conjunction rule generates two new, smaller assertions: 

I : S and T <=> I : S, I : T. 
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The rules simplify terminological constraints until a normal form is reached. 
The normal form is either false (inconsistent) or contains constraints of the form 
I : C, I : nota C, I ; S or T, I : every R is S and (I, J) : R, where 
C is a primitive concept name. There are no clashes and the value restriction 
has been propagated to every object. To achieve completeness, search must be 
employed. This is done by splitting I : S or T into two cases, I : S and I : T. 



Termination. The only CHR constraints that are rewritten by the rules are 
membership assertions. Since there are no guards, to show termination it the- 
refore suffices to show that in each rule, the membership assertions in the body 
are strictly smaller than the ones in the head. 

To prove termination we order concept terms by the following ranking: 

rank{{A A B)) = rank{A) + rank{B) 

rank {{I, J) : r) = 0 

rank {I : s) = rank{s) 

rank{nota s) = 2 * rank{s) 

rank(c) = 1 -|- rank(s) if (c isa s) exists 

rank(f(ti, . . . ,tn)) = 1 + rank{ti) rank(tn) otherwise 

The ranking above is well-founded, since concept definitions c isa s are acyclic 
and finite by definition. From the ranking we can see that goals are bounded 
if the ranks of all concept terms (like s and c) are known. Since concept terms 
are ground (variable- free) and finite by definition, their ranks can always be 
computed. 

The propagation rule for value restrictions needs closer consideration. Note 
three things: First, the rank of its body is strictly smaller than the rank of its 
head. Second, since a propagation rule is applicable only at most once to the same 
constraints, it can only be applied a finite number of times to a finite conjunction 
of constraints. Third, the ranking is well-founded and goals are bounded. For 
these reasons, the propagation rule can only generate a finite number of smaller 
and smaller membership assertions. 



4.3 Linear Polynomial Equations 

For solving linear polynomial equations, a minimalistic but powerful variant of 
variable elimination [rmb95| is employed in the available CHR constraint solvers. 

Definition 14. A linear polynomial equation is of the form p + b — 0 where b is 
a constant and the polynomial p is the sum of monomials of the form * Xi with 
coefficient yf 0 and Xi is a variable. Constants and coefficients are numbers. 
Variables are totally ordered by )^. In an equation ai*Xi + ... + an* Xn + b = 0, 
variables appear in strictly descending order. 

In constraint logic programming, constraints are added incrementally. The- 
refore we cannot eliminate a variable in all other equations at once, but rather 
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consider the other equations one by one. A simple normal form can exhibit incon- 
sistency: It suffices if the left-most variable of each equation is the only left-most 
occurrence of this variable. Therefore the two rules below implement a complete 
and rather efficient solver for linear equations over both floating point numbers 
(to approximate real numbers) and rational numbers. In the implementation, we 
write eq for equality on polynomials. 

empty 0 B eq 0 <=> number (B) I B=0 . 
eliminate 0 

A1*X+P1 eq 0, A2*X+P2 eq 0 <=> 
compute(P2-Pl*A2/Al ,P3) , 

A1*X+P1 eq 0, P3 eq 0. 

The empty rule says that if the polynomial contains no more variables, the con- 
stant B must be (approximate to) zero. The eliminate rule performs variable 
elimination. It takes two equations that start with the same variable. The first 
equation is left unchanged, it is used to eliminate the occurrence of the common 
variable in the second equation. The auxiliary built-in constraint compute sim- 
plifies a polynomial arithmetic expression into a new polynomial. No variable is 
made explicit, i.e. no pivoting is performed. Any two equations with the same 
first variable can react with each other. Therefore, the solver is highly concurrent 
and distributed. 

The solver can be extended by a few rules to create explicit variable bindings, 
to make implicit equalities between variables explicit, to deal with inequations 
using slack variables or Fourier’s algorithm. 



Termination. Since in termination proofs we can ignore rules whose body 
contains only built-in constraints, we are only concerned with the eliminate rule 
here. To prove its termination we order the equations by the following ranking 
mrank that uses a multi-set order on the variables occurring in goals. The 
order is induced by the order on ranked variables the ranking function rank 
itself is not defined for any predicate or function symbols. 

mrank{{A A B)) = mrank{A) U mrank{B) 

mrank{P eq 0) = mrank{P) 

mrank {A) = {} if A is a built-in constraint 

mrank{T) = {rank{V) | y is a variable in T} if T is a term 

ai * Xi + . . . + an * Xn + b eq 0 ^ Xi >- Xj for all n > z > j > 1 (1) 

compute{E, P) — >■ mrank{E) A mrank{P) (2) 

The order constraint (1) says that the monomials in the equations are ordered 
by their variables. The order constraints (2) says that the built-in constraint 
compute does not introduce new variables, but may eliminate occurrences of 



some. 
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For better readability, we will now just write the polynomial P instead of 
mrank{P) and the variable V instead of rank{V). From the eliminate rule we 
get that the head rank, the multi-set ({X} U Pi U {X} U P2), must be strictly 
larger than the body rank ({X}UPi UPS). From the order constraint (2) we can 
derive that P 2 UPi U PS. Hence the body rank multi-set contains only variables 
from the head rank multi-set. Due to (1) we know that the variable X does not 
occur in Pi,P 2 and P 3 , and that it comes before all other variables in Pi,P 2 
and P 3 in the variable order. Therefore the head rank multi-set is strictly larger 
in the multi-set order than the body rank multi-set, because in the former X 
occurs twice and in the latter X occurs only once. 

The order of the monomials by variables in the polynomial equations corre- 
sponds to an implementation of the multi-set order by a lexicographic order as 
mentioned at the end of section 01 

4.4 Path Consistency 

In this section we analyze termination of constraint solvers that implement in- 
stances of the classical artificial intelligence algorithm of path consistency to 
simplify constraint satisfaction problems !MaFr85| . 

Definition 15. A binary constraint network consists of a set of variables and 
a set of (disjunctive) binary constraints between them. The network can be 
represented by a directed constraint graph, where the nodes denote variables and 
the arcs are labeled by binary constraints. Logically, a network is a conjunction 
of binary constraints. 

Definition 16. A disjunctive binary constraint cxy between two variables X 
and Y, also written X {ri, . . . ,r„} Y, is a finite disjunction {X r^ T) V . . . V 
{X r„ y), where each is a relation that is applicable to X and Y. The Vi are 
called primitive constraints. The converse of a primitive constraint r between X 
and Y is the primitive constraint s that holds between Y and A as a consequence. 

For example, A {<} B,A {<, >} B,A {<,=, >} B are disjunctive binary con- 
straints CAB between A and B. A {<} B is the same as A < B, A {<, >} B is the 
same as A ^ B. Finally, A {<,=, >} B does not impose any restrictions on A 
and B, the constraint is redundant. Usually, the number of primitive constraints 
is finite and they are pairwise disjoint. We will assume this in the following. 

Definition 17. A network is path consistent if for pairs of nodes (i,j) and all 
paths i — i\ — i 2 ■ ■ - in ~ j between them, the direct constraint is at least as 
tight as the indirect constraint along the path, i.e. the composition of constraints 
along the path denoted by ® ® Ci^j- A constraint Cij is tighter than a 

constraint dij iff implies dij. 

It follows from the definition of path consistency that we can intersect the 
direct and indirect constraint to arrive at a tighter direct constraint. Let inters- 
ection be denoted by the operator ©. A graph is complete if there is a pair of arcs. 
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one in each direction, between every pair of nodes. If the graph underlying the 
network is complete it suffices to repeatedly consider paths of length 2 at most: 
For each triple of nodes (i,k,j) we repeatedly compute := © (c^fc © Ckj) 

until a fixpoint is reached. This is the basic path consistency algorithm. 

Example 3. Given I < K A K < J A I > J and taking the triple (i,k,j), 
Cik © Ckj results in / < J and the result of intersecting it with Cij is I = J. From 
(j,i,k) we get J = K (we can compute Cji as the converse of c^). From (k,j,i) 
we get K = I. Another round of computation causes no more change, so the 
fixpoint is reached with J = K A K = I. 

Let the constraint Cij be represented by the CHR constraint c(I, J,C) where 
I and J are the variables and C is a set of primitive constraints representing 
Cij. The basic operation of path consistency, c^- := © {cik © Ckj), can be 

implemented directly by the rule: 

path_consistency 0 

c(I,K,Cl), c(K,J,C2), c(I,J,C3) <=> 

composition (Cl, C2,C12) , intersection(C12,C3,C123) , 

C123=\=C3 I 

c(I,K,Cl), c(K,J,C2), c(I,J,C123). 

The operations © and © are implemented by built-in constraints, composition 
and intersection. Composition of disjunctive constraints can be computed 
by pairwise composition of its primitive constraints. Intersection for disjunctive 
constraints can be implemented by set intersection. To achieve completeness, 
search must be employed. This is done by imposing primitive constraints chosen 
from the disjunctive constraints. 



Termination. To prove termination we rely on the cardinality of the sets re- 
presenting the disjunctive constraints and the properties of set intersection: 

rank{{A A B)) = rank{A) + rank{B) 
rank{c{I ,K,C)) = cardinality {C) 
rank {A) = 0 otherwise 

intersection{CA,C2,C3) — >■ rank{C3) < rank{CA)Arank{C3) < rank{C2) 
inter sectioned, C2, (73) A (73 ^ (72 — >■ rank{C3) yf rank{C2) 

Since in the guard of the rule, C123=\=C3 is checked to make sure the new 
constraint C123 is different from the old one C3, the cardinality of C123 must be 
strictly less than that of C3. Hence the body is ranked strictly smaller than the 
head of the rule. Goals are bounded, when (7 is a known, finite set of primitive 
constraints. Any solver derived from this generic path consistency solver will 
terminate, too. 
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4.5 Interval Constraints, Arc Consistency 

The following rules implement an arc consistency algorithm for interval con- 
straints . Arc consistency can be seen as special case of path consistency, 

where all but one constraint is unary instead of binary. The interval constraint 
X in A:B means that X is an integer between the given bounds A and B. 

7o Intervals 

inconsistent ® X in A:B <=> A>B I false. 

intersection @ X in A:B, X in C;D <=> A=<B I X in max(A,C) :min(B,D) . 



7o (In) equalities 

le @ X le Y, X in A:B, Y in C:D <=> A=<B,B>D I 

X le Y, X in A:D, Y in C:D. 

le @ X le Y, X in A:B, Y in C:D <=> C=<D,C<A I 

X le Y, X in A:B, Y in A:D. 

eq @ X eq Y, X in A:B, Y in C:D <=> A=<B,C=<D,A=\=C I 

X eq Y, X in max(A,C) :B, Y in max(C,A):D. 

eq @ X eq Y, X in A:B, Y in C:D <=> A=<B,C=<D,B=\=D I 

X eq Y, X in A:min(B,D), Y in C:min(D,B) . 



7o Addition X+Y=Z 

add @ add(X,Y,Z), X in A:B, Y in C:D, Z in E:F <=> 

A=<B,C=<D, not((A>=E-D,B=<F-C,C>=E-B,D=<F-A,E>=A+C,F=<B+D)) I 
add(X,Y,Z) , 

X in max(A,E-D) ;min(B,F-C) , 

Y in max(C,E-B) :min(D,F-A) , 

Z in max(E, A+C) ;min(F,B+D) . 



To achieve completeness, search must be employed. This is done by splitting 
intervals in two halves or by trying the boundary values of an interval. 



Termination. We order constraints by the size of their intervals: 

rank{{C A D)) = rank{C) + rank{D) 
rank\x in A \ B) = B — A + 1 \i B > A 
rank{C) = 0 otherwise 

We will use the inequalities in the guards of the rules directly as order constraints. 
With their help we can prove that in each rule, at least one interval in the body 
is strictly smaller than the corresponding interval in the head, while the other 
intervals remain unchanged or will be removed. 

The constraints A=<B and C=<D in the guard of a rule ensure that the rank of 
the head of the rule cannot be 0. (In implementations that apply rules in textual 
order, these guard constraints can be dropped.) The ranking condition for the 
first rule inconsistent also holds, even though its head rank is 0, since its order 
constraint is inconsistent: {A > B A false) — >■ 0 > 0. 
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Since the interval bounds are initially known, goals are bounded. Note that 
the intervals of integers are closed under the interval computations used, since 
they involve only the arithmetic operations max, min and +, Termination 
for intervals of rational numbers can be shown by observing that any problem 
on rational numbers can be transformed into an equivalent one on integers by 
multiplying all numbers the problem with their greatest common divisor. For 
floating point numbers, rounding errors get in the way. 

5 Conclusions 

We have shown in this paper that for many known constraint solvers imple- 
mented in CHR it is possible to prove termination by adapting well-founded 
orders (linear polynomial interpretations) and interargument relations (order 
constraints) as known from related work in term rewriting systems and logic 
programming. One adaption was to extend termination order from atomic for- 
mulas to conjunctions of constraints. 

To the best of our knowledge, this is the first report on proving termination 
of concurrent constraint logic programs and of constraint solver implementati- 
ons. Our results indicate that in practice, proving termination for concurrent 
constraint logic programs may not be harder than for other classes of logic pro- 
gramming languages, contrary to what has been feared in the literature. 

Our results so far are somewhat unsatisfactory, because we give two analogous 
Theorems which should be abstracted into single Theorem accomodating both 
kind of termination orders that we considered (polynomial interpreations and 
multi-sets). 

The solvers we have considered are characterized by the fact that recursion is 
direct and typically modifies one argument position of a constraint, and the term 
in that position is sufficiently known in reasonable queries, i.e. those queries are 
bounded. 

Although we have dealt with termination in the presence of propagation rules 
in the solver for terminological reasoning, we still have to formalize termination 
involving propagation rules. In particular, there is a class of solvers that we 
currently cannot prove to terminate with the approach presented in this pa- 
per. These solvers are implementations of path and arc consistency algorithms 
on incomplete constraint networks. They basically consist of the two following 
prototypical rules: 

c(I,K,Cl), c(K,J,C2) ==> composition(Cl,C2,C3) , c(I,J,C3). 
c(I,J,Cl), c(I,J,C2) <=> intersection(Cl,C2,C3) , c(I,J,C3). 

These solvers have recursion on the same constraint through both simplification 
and propagation rules. This means that a constraint can be first added and then 
be removed during the computation. To prove termination, one will have to take 
into account that simplification is applied sufficiently often before propagation 
and the fact that propagation rules are never applied a second time to the same 
constraints. 
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Future work will also consider automation of the termination proofs presented 
here. Another interesting line of future work is to strengthen the antecedent of 
a ranking condition by introducing type constraints (since ill-typed goals either 
delay or fail). 

Acknowledgements. The author would like to thank the anonymous reviewers 
for their valuable suggestions. 
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Abstract. Constraint solving in dynamic environments requires an im- 
mediate adaptation of the solutions if the constraint problems are chan- 
ging. Constraint solving with Constraint Handling Rules (CHR) is exten- 
ded with incremental algorithms, thus supporting the solution of dyna- 
mic constraint satisfaction problems (DCSPs). Unfortunately, constraint 
processing with CHR introduces a lot of new variables which require ad- 
ditional memory space and reduce run-time performance. Most of the va- 
riables may be eliminated without any loss of information. Thus, memory 
may be kept rather small and run-time performance may be improved. 
This paper describes the use of projection with CHR in order to elimi- 
nate irrelevant variable bindings and maintain the constraint store quite 
small. In detail, some projection algorithms are presented to eliminate 
variables which are introduced during constraint processing with CHR. 
Projection is called early projection if it is applied together with each rule 
application, thus eliminating recently introduced irrelevant variable bin- 
dings while keeping the derived constraint store quite small. This kind of 
projection is well-suited when solving Dynamic Constraint Satisfaction 
Problems, especially after constraint deletion, when many superfluous 
variable binding have to be deleted as well. Consequently, the modifica- 
tions that are required for an adaptation are reduced. This may result 
in an improved performance of the adaptation algorithms and a bet- 
ter performance for non-adaptive constraint processing with CHR is also 
expected. 



1 Introduction and Motivation 

Structured programming brought into existence the concept of procedures and 
with them the so-called local variables, i.e. certain pieces of memory keeping 
information during the procedures’ activation. Usually, at the beginning of a 
procedure’s life-time, an activation record at a global stack is allocated. This 
has the advantage that this piece of memory is automatically deallocated at the 
end of the procedure’s life-time. However, the concept of pointers or references 
is not supported. Thus, the user has to maintain the allocation and deallocation 
of memory. He or she has to be very careful otherwise ‘dangling’ references are 
created, a rich source of run-time errors. 

High level programming languages such as LISP, PROLOG and Constraint 
Logic Programming (CLP) languages tackle the reference problem by allowing a 
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few dynamic data constructors which are automatically allocated. The principle 
of garbage collection ca was introduced to detect still allocated but unreferenced 
data and deallocate its memory. 

The work in this paper can be seen as an extention of this principle. Before 
any garbage collection, data structures - in our case term structures - are sim- 
plified such that references from and to local variables are removed. Then the 
memory of unreferenced data (terms) is deallocated. 

Example 1. Let the syntactical equations x = f{u,v),u = v,v = y he given 
where x and y are global variables and u and v local ones. It is assumed that 
the variables are pointing to (or bound to) the terms at the left-hand-sides of 
the equations. Dereferencing the local variables simplifies the equations. The 
result X = f{y, y),u = v,v = y shows that there is no reference from a global to 
a local variable. Thus, the local variables and the terms, they are pointing to, 
are eliminable. After an elimination only the equation x = f{y,y) survives, the 
variables u and v are deallocated. 

The removal of local variables from formulas, preserving equivalence, is of- 
ten referred to as quantifier elimination or projection. From a logical point of 
view, the elimination of variables means that a formula 3xF is replaced by an 
equivalent formula G where most - ideally all - existentially quantified variables 
in X are eliminated. With respect to a theory £ that defines the semantics of the 
formulas it holds 



£ h o G 

From a geometrical point of view, elimination of local variables means the pro- 
jection of a space spanned by some equations or inequations onto the space that 
is spanned by the global variables (see Figure Pi. For instance, the projection of 



z 




Fig. 1. Projection of a sphere on a plane. 



the triangle defined byy>l,a;>?/, 3?/<6 — a: onto the x-axis yields 1 < a; < 3. 

In this paper, the elimination of local variables is presented in the context 
of adaptive constraint handling based on Constraint Handling Rules (CHR). 
CHR \ ,3] are a high-level, declarative language extension of the CLP scheme. 
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especially developed to implement special-purpose constraint solvers for user- 
defined constraints. CHR are rewriting rules that are used to simplify and solve 
constraints. There are propagation and simplification rules. Propagation rules are 
used to make implicitly given constraints explicitly available, e.g. the transitivity 
of the mathematical order relation “<” may be represented by the rule X<Y,Y<Z 
==> X<Z. This additional information may be used for further simplifications. 
Simplification rules are used to simplify constraints, especially to detect clashes, 
e.g. the asymmetry of “<” may be reflected by the rule X<Y,Y<X ==> false. 

Example 2. The rule 



P + Q = C^R\sC-Q\P = R. 

solves the simple linear equation X -|- 3 = 5 but a lot of local variables and 
equations are introduced: The matching of the head of the rule binds P to X, 
Q to 3, and C to 5. The computation in the guard of the rule binds X to 2. At 
last, in the body of the rule, P is bound R. Thus, the equations 

P = X,Q = S,C = 5,R = 2,X = 2 

are generated and memory is used to store them. The really important infor- 
mation, i.e. X = 2, is accompanied with a lot of ‘garbage’. The number of new 
variables and their bindings can increase dramatically during a CHR derivation, 
i.e. during successive rule applications (a more detailed example is presented in 
the next section). 

Considering dynamic constraint satisfaction problems, especially after con- 
straint deletions, CHR derivations must be adapted. Without elimination of local 
variables, many superfluous variable bindings depending on the deleted con- 
straints have to be deleted as well. Thus, for memory but also for run-time 
efficiency matters, variable eliminations are presented that are compatible with 
our previously presented adaptation algorithms m- 

After an brief introduction into the technicalities about CHR and the ad- 
aptation of CHR derivations (Section 0, two special kinds of projections are 
presented. Both are based on a substitution that substitutes all eliminable va- 
riables (Section 0 ■ An iterative algorithm to compute this substitution based 
on some fix-point properties is presented together with some time complexity 
considerations. The so-called early projection (Sectional is designed to improve 
run-time efficiency during the adaptation of CHR derivations. It is an adoption 
of the ideas presented in uncu) ; instead of linear equations and inequations, 
syntactical equations are considered. The goal of the so-called answer projection 
(Section is the better readability of the constraints at the end of a constraint 
handling process. The paper finishes with a conclusion and the planned future 
work (Section El . 
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2 Technicalities about CHR 

The syntax and declarative semantics of CHR is taken from ini An alternative 
operational semantics of CHR is presented which is sound with respect to their 
declarative semantics m- 



2.1 Built-in and User-Defined Constraints 

Constraints that are handled by CHR are considered to be atomic, first-order 
formulas. It is assumed that there are two disjoint sorts of predicate symbols 
and constraints: built-in and user-defined. Intuitively, built-in constraints are 
axiomatized by some constraint theory and handled by an appropriate constraint 
solver. User-defined constraints are defined by a CHR program. 

In the following the built-in constraints are syntactical equations, equations 
over the rational trees. Syntactically these are atomic formulas s = t where s 
and t are first-order terms. Rational trees are either finite trees or infinite trees 
having finitely many subtrees 0. Their nodes are function symbols. Each n-ary 
function symbol has n successors. A complete axiomatization of the equality over 
rational trees, called Ef, is given in m- The equality theory over the rational 
trees is more general than that over the finite trees. For instance, considering the 
two syntactical equations x = f{y) and y = g{x) {x and y are variables) there are 
no finite trees solving these equations simultaneously, but there is a rational tree 
solution, namely x = f{g{f{g {. . .)))) and y = g{f{g{f{. . •)))). Rational trees are 
preferred over finite trees because there are a more adequate abstraction of the 
native constraints solvers in CLP systems ignoring the occurs check and thus 
running infinitely while trying to solve the considered equations. 



2.2 Syntax of CHR 

A CHR program is a finite set of constraint handling rules. There are two basic 
kinds of CHR: 

— Simplification rules: Hi, . . . , Hi G\, . . . ,Gj \ Bi,...,Bk . 

— Propagation rules: Hi, . . . , Hi ^ Gi, . . . ,Gj \ Bi,...,Bk . 

The head Hi, ..., Hi is a, non-empty, finite sequence of user-defined constraints, 
the guard Gi, ... ,Gj is a possibly empty, finite sequence of built-in constraints, 
and the body Bi, . . ^Bk, is a possibly empty, finite sequence of user-defined and 
built-in constraintslj 

Optionally the rules are named. A name precedes the rule and is separated by 
the symbol If the guard is empty, the symbol “|” is omitted. Furthermore, it 
is assumed that the body is partitioned into user-defined and built-in constraints. 

For conjunctions in rules is used instead of “A” . 



1 
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2.3 Declarative Semantics 

The semantics of user-defined constraints is given by a logical reading of the CHR: 
For every CHR program P, there is a set of first-order formulas V containing a 
closed formula for each rule in P. The semantics of the user-defined constraints 
are the models of P. 

Let ^ \ or ^ | 

i?i, . . . , Bfe be a CHR. Furthermore, let x be the set of variables occurring in the 
head Hi,. .. ,Hi and the guard Gi , . . . , G^ and let z be the set of variables only 
occurring in the body B\, . . . , Bk and neither in the head nor in the guard of 
that rule. 

The logical reading of the rule Hi, . . . , Hi ^ Gi, . . . ,Gj \ Bi,. . . ,Bk is 
Vs ((Gi A ... A Gj) {Hi A . . . A iJi O {Bi A ... A Bfc))) . 

The logical reading of the rule Hi, . . . ,Hi ^ Gi, . . . ,Gj \ Bi, . . . , B^ \s 
Vs ((Gi A . . . A Gj) ^ (TVi A . . . A ^ (Bi A . . . A Bk))) . 



2.4 Operational Semantics of CHR 

The operational semantics of CHR is defined by a transition system (cf. 1 1 1,'ij 1 : 
The states are annotated pairs 



{Cu,Cb)u ■ 



Gjj is a conjunction of user-defined constraints called user-defined store, Gb 
a conjunction of built-in constraints called built-in store, and v is the set of 
variables one is interested in. Other variables may be constrained, too, but they 
are out of interest. The semantics of the user-defined constraints are given by 
the CHR which are defined to simplify and to solve these constraints. 

For adaptation of the results of constraint processing using CHR, i.e. of the 
CHR derivations, it it necessary to modify the states and transitions Some 
simplifications of the techniques known from assumption based truth mainten- 
ance systems (ATMS) [iSI9ll8j are used: the constraints are marked with their 
justifications, i.e. finite sets of numbers which identify the currently valid con- 
straints. Thus, the initial constraints are justified by themselves. The built-in 
store is a solution triple, i.e. the result of an adaptive unification algorithm unify 
which normalizes marked syntactical equations (cf. [122)1. Given a list of marked 
syntactical equations E, unify computes a solution triple: 

unify(£;) = unME, (T, 0, [])) = (O, I, A) . 

The tag O either signals consistency, i.e. E* fy 3E, (O = T) or inconsistency, 
i.e. E* ^ 3E, (O = T) H J is a set of marked variable bindings in rational solved 
form (cf. f1 ti)l. In the case of consistency, I is equivalent to the equations in E, 

^ 3E is the existential closure of the conjunction of all equations in E. 
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i.e. E* \= E ^ I. A, and this really is new, is a list of some marked equations 
from the input which have to be reconsidered after some deletions. During the 
iterative process of unification, the previously calculated solution triple is part 
of the input in the next step. 

Example 3. Let it, y, z be variables, c a constant, and / a function symbol. Fur- 
thermore, a list of marked syntactical equations 

E=[{x = f{x, y))^^\ {f{z, c) = 

is given. The left- and right-hand sides of the equations are unified iteratively. 

At the beginning of the first iteration step, no variables are bound and the 
equation {x = f{x,y))^^^ becomes part of the rational solved form: 

unify(F;) = unify([(/( 2 ;,c) A (T, {(x = f{x,y))^^^ },[])) . 

An additional storage of this equation for further consideration is not necessary 
because it is part of the rational solved form. Thus, the third argument of the 
triple is the empty list. 

In the second step, the equation {f{z,c) = x)^^^ is considered. Therefore, 
the variable x is dereferenced: The involved variable bindings are traversed until 
the end of the chain is reached and the labels are combined. This yields the 
new equation {f{z, c) = /(x, for solution. For the unification of its sides, 

the arguments are equated and the unification process is recursively applied 
to the list of marked equations and the intermediate result, the solution triple 
calculated so far: 

unify(if) = unify([(z = (c = y)^^’%{T,{{x = /(x, y)){i>}, [])) 

During consideration of the first equation, the variable x is dereferenced again. 
Consequently, the rational solved form obtained is extended by the new binding 
{z = f{x,y))^^’‘^\ Processing the other equation (c A adds the binding 

{y A because the variable y was unbound. The final result is the solution 

triple 

(T, {(a: A /(x,y))^^^ (z A /(x,y))^^’2^ (y A [(/(z, c) A x)^^^])) . 

The initially given equation (/(z, c) A is stored for reconsideration. This 

is necessary because a deletion of equations and bindings marked with 1, which 
may occur later, deletes the bindings of y and z. Thus, the still valid equation 
(/(z,c) A is not respected in the rational solved form and has to be 

reconsidered. 

To sum up, the considered states are annotated pairs 

{Cu,{OJ,A))^ 

where I are variable bindings in rational solved form and (T, 0 , []) is the empty 
built-in store. The logical reading of a state {Cu, (O, I, A))~ is 

3u; {Cu A /) if O = T and false if O = T 

where w are the variables in Cjj and / but not in u.0 
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The transitions defining the operational semantics of CHR are based on some 
conventions and notations: Capital letters denote finite sequences or conjunctions 
of constraints. Without the loss of generality, it is assumed that the body of a 
CHR is partitioned into user-defined and built-in constraints: The CHR are of 
the respective forms p @ H G \ U,B and p @ H ^ G \ U, B. p denotes the 
name of the rule and is separated by H is the head of the rule, a conjunction 
of user-defined constraints. G is the (optional) guard of the rule, a conjunction 
of syntactical equations. The body of the rule is partitioned in a conjunction of 
user-defined constraints U and a conjunction of syntactical equations B. 

Transitions are defined by rule applications: A CHR is applicable to a state, 
if the built-in store is consistent and if there are marked constraints in the user- 
defined store that matches its head and if the guard holds, both with respect to 
the built-in store. This is decided with help of an adaptive entailment procedure 
called entail (for details, see |2I1)- Given some existential or local variables x, a 
set of marked variable bindings I containing only global variables, and a list of 
marked syntactical equations F, entail computes an annotated solution triple: 

entail(x, I, F) = entail(x, I, F, (T, 0, [])®) = (A, J, D)^ 

The tag A either signals entailment, i.e. E* \= I ^ 3xF, (A = T) or disentail- 
ment, i.e. A* ^ 3xF, (A = T). J is a set of marked local variable bindings 
in rational solved form (cf. cni) solving the equations F with respect to I. In 
the case of entailment, / A J is equivalent to I A F, i.e. E* ^ (J A J) O (/ A F). 
Furthermore, / U F is in rational solved form. F is a list of some marked equati- 
ons from F to be re-considered after some deletions. If entailment is given, the 
annotated label S justifies it. More specifically, the label is the union of all labels 
of the required global variable bindings and the entailed equations. Thus, 

entail(S,/',F) = (T, J,F)^ 

holds for every set of marked syntactical equations F in rational solved form 
with its variables disjoint to x and that contains all variable bindings in / which 
are marked with subsets of S. 

Example 4- Let {a:} be a set of local variables and I = {{u = < 7 (u))^^^} a set of 
marked global variable bindings in rational solved form. Furthermore, a list of 
marked equations 



F=mu) = f{g{x)))^^^] 

is given. Iteratively, it is decided whether f{u) = f{g{x)) is implied by I, and 
an equivalent set of variable bindings in rational solved form is calculated. 

At the beginning, no local variables are bound. The equation (/(it) = 
/(( 7 (a;)))G} is entailed, if and only if, (it = ^(a:))^} is entailed. Dereferencing u 
with respect to I results in g{v). Thus, the question is whether {v = a;)^’^}) is 

The logical reading of I is the conjunction of the variable bindings in I. 



3 
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entailed or not. The decision is simple because there is an appropriate binding 
of X, namely to v. Thus, it holds 

entail({a;}, I, F) = (T, {(?; = [{f{u) = f{g{x)))^^^)^^'^ . 

The binding has become part of the rational solved form and the initially given 
equation {f{u) = f{g{x)))^^^ is entailed. This equation has to be stored for fur- 
ther adaptations because deletion of the global binding {u = g{v))^^^ endangers 
entailment of this equation and has to be re-decided. The information that ent- 
ailment is justified by bindings marked with {1} is given by the annotation of 
the solution triple. 

To decide head matching and guard entailment using entail, the local varia- 
bles X are the variables of a new variant of a CHR which should be applied. The 
bindings of the (global) variables in the rational solved form I are from the built- 
in store. The equations F that are checked for entailment are the equations in 
the guard and the equations one achieves by equating some selected constraints 
from the user-defined store and the head of the rule variant to be applied. 

By equating two marked user-defined constraint^, say (c(si, . . . , s„))^ = 
(c(ti, . . . ,tn))^, the conjunction (si = A ... A (s„ = is meant. By 

equating two conjunctions of marked constraints (pi A . . . Apm) = (gi A . . . A qm)-, 
the conjunction pi = gi A . . . A Pm = Qm is meant. 

The entailment procedure computes an annotated solution triple, i.e. 

entail(x, I, {H = H') A G) = (A, J, Of 

that decides the applicability of the considered CHR variant. In the case of head 
matching and guard entailment (A = T), the rule is applied to the current state. 
In this case, the head matching constraints in the user-defined store are either 
replaced by the user-defined constraints in the body (the CHR is a simplification 
rule) or extended by these constraints (the CHR is a propagation rule). Furt- 
hermore, the built-in store is extended by the local variable bindings and the 
equations in the body are unified with respect to the global and local variable 
bindings. To make this transition to the new state adaptable, all added con- 
straints are justified by the justification of head matching a guard entailment S 
and by a unique identifier p of the applied CHR. Therefore, ||G||'^^^^^ denotes 
that the constraints in C are marked with S' U {p}. 

For any further adaptation, it is also necessary to store the following infor- 
mation together with the identifier p of the applied rule: 

— the local variables x, 

— the replaced user-defined constraints H' to be taken back, if the rule will be 
eliminated, 

— the bindings of the local variables J that have to be adapted after some 
constraint deletions, 

— some of entailed equations D which have to be reconsidered to adapt J, 
Non-marked constraints are considered as to be marked with the empty set. 
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— the justification S for head matching and guard entailment. 

In the case of any constraint deletion, the justification S is used to decide the 
validity of the transition: The transition is - without doubt - still valid if the 
labels of the deleted constraints are disjoint to S. 

Definition 1. Given a CHR program P (a set o/CHRJ we define a transition 
relation between states by introducing two kinds o/rule applications called 

Simplify 

{p @ H G \ U, B) is a fresh variant of a simplification rule in P 
with variables x and it holds entail(a;, I, {H = H') A G) = (T, J, D)^ . 



{H' ^CufiT, I, A))^ 



Propagate 

{p @ H ^ G \ U, B) is a fresh variant of a propagation rule in P 
with variables x and it holds entail(a;, I, {H = H') A G) = (T, J, D)^ . 



{H' 

(i/'AGc/A||C/fuM,unify(||i?pu{p}^(T^jLJ||jfuM,A)))- 

As already mentioned, the built-in store is extended by all the computed 
variable bindings. Thus, the states in a CHR derivation quickly grow which in- 
creases the efforts needed to adapt the derivation after some changes of the 
constraints to be solved. The following example shows the effects of the addition 
of all the computed variable bindings. 

Example 5. Applying the following CHR program 

p^@7pAC^P = C. 

P 2 @1P + 1Q = C number((5), i? \s C — Q \ P = R. 

P 3 @7P + 7Q = C number(P), i? \s C — P \ Q = R. 

P4@7P + 7Q = C,1P-1Q = R\s {C + D)/2\P = R,1P + 7Q = C. 

to the following marked linear equations 

{7X + 7Y = 3)^^^ {7Y = (?[/ -7V = 2)^^\{7U + 7V = 0)^^^ 

results in the following CHR derivation that solves these linear equations: 

{{7X + 7Y = A {7Y = 2)^2} a {7U - 7V = 2){3l a {7U + 7V = 

(T,0, [])) {X,Y,U,V} 

{{7X + 7Y = 3){i> A {7U -7V = 2){3l a {7U + 7V = 
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(T, {(Pi = (Cl = 2){2}, (y = 

((?P -W = 2){3} A {lU + ?y = 

(T,|(Pi AF){2 }^(C'i =2){">,(y A2){2>, 

(P 2 = (Q 2 = 2)^^-'^\{C2 = 

^p, ((?P4 + ?g4 = C4){3’">, 

(T,|(Pi = r){2>,(Ci =2){2},(y = 2){2}, 

(P 2 A (Q 2 = (C 2 = 

(P 2 A 1^{1,2}^ 

(P 4 = P){3.4}^ (Q^ = y){3.4}^ = 0){3.4}, 

(P 4 = 2 ){ 3 . 4 }, (i ?4 = 1){3.4}^ (JJ = l){3,4}}^ [])){xya.n 

^P3 (T ; 

(T,|(Pi = r){2>,(Ci =2){2},(y = 2){2}, 

(P 2 = (Q 2 = 2){i’">, (C 2 = 3){1’2>, 

(P 2 A 1^{1,2}^ 

(P 4 A P){3.4}^ ^ ^^{3.4}^ = 0){3.4}, 

(P 4 = 2){3.4}^ = 1){3.4}^ (JJ = 1){3.4}^ 

(P 3 = P4){3.4}, (Q3 = Q4){3.4}^ (^3 = C4)^"’">, 

(i?3 = _l){3.4}^(y = _l){3.4}}J]))^^^^_^_^j . 

This example impressively shows that the states are growing during constraint 
processing and that the relevant information, i.e. the computed values of the 
variables of interest, is covered by a lot of other variable bindings out of inte- 
rest. Furthermore, the deletion of some initial constraints, e.g. marked with 2, 
requires the deletion of several local variable bindings, which are not really ne- 
cessary. To improve this unsatisfying situation, the elimination of local variables 
is proposed. Variable elimination is also considered in previous works on CHR: A 
normalization function is defined that substitutes variables and replaces built-in 
constraint stores |E] (cf. Definition 2.7). In P| built-in constraint stores are upda- 
ted (cf. Definition 6 ). Update substitutes variables and eliminates local variable 
bindings. However, both approaches are only sketching a general guideline. De- 
tailed considerations are missing because the theory of the built-in constraints 
is not fixed. A more detailed approach, where the constraint theory is fixed to 
be E*, is presented in the rest of this paper. 

3 Substitutions — The Basis of Variable Eliminations 



Algorithms that eliminate existentially quantified variables in first order for- 
mulas while keeping their semantics are often called projection algorithms (cf. 
Section 0. In general, it is impossible to eliminate all existentially quantified 
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variables. For instance, in the formula 3it3z ; x = f{u) Au = g{v) it is possible to 
eliminate the variable u but it is impossible to eliminate v. This means that the 
result of projection will be the formula 3vx = f{g(v)) and it holds 

E* ^ (3u3v X = f{u) Au = g{v)) ^ {3vx = f{g{v))) . 

In what follows, an algorithm is presented that computes a substitution. With 
its usage, some of the local variables introduced in the states of CHR derivations 
during constraint processing are eliminated. Only the necessary local variables 
are retained. In detail, a substitution which is the fix-point of a so-called pro- 
jection function is evaluated by iteration. This substitution is applied to the 
body constraints of the applied rules before they are added to the state to which 
the rule is applied to. Based on this substitution, the necessary local variable 
bindings are determined. All other local variable bindings are removed either at 
each rule application or in the final state of a derivation. 

3.1 The Computation of the Required Substitutions 

The computation of the substitution requires an evaluation of the variables to 
be substituted and the terms substituting them. Therefore, the terms that are 
bound to the variables are unrolled. Considering rational trees, a stepwise re- 
placement of the variables by the terms they are bound to is not sufficient to 
compute the substitution: 

Example 6. Let the set of variable bindings {z = f{x),x = g{y),y = h{x)} 
in rational solved form be given. Then, the stepwise replacement of x and y to 
determine the substitution of z will not terminate. One gets the infinite sequence 
of terms f{x)J{g{y))J{g{h{x))),f{g{h{g{y))))J{g{h{g{h{x ))))), .... 

Cycles that are defined by variable bindings (as x and y in the example) 
distinguish rational from finite trees. Non-termination of the computation of the 
substitution caused by cycles in rational trees is avoided if bounded variables 
are replaced at most once. 

Definition 2 (Substitution). Let V be the set of variables and T the corre- 
sponding set of terms (with respect to a given signature)^ A substitution is a 
function cr : V — ^ T such that 

<j{x) = X holds for almost all x £V . 

The canonical extension that maps terms to terms is the function a \ T ^ E 
with 



a(c) = c 

a(f(ti,...,tn)) = f(cr(ti),...,a(t„)) 

for every constant c G E, for every n-ary function symbol f, and any arbitrary 
terms ti, . . . ,tn G E. 



® For an introduction into first order logics, m is recommended. 
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By convention ta or Aa is written instead of a{t) respective cr(A). Further- 
more, a substitution is often represented by a finite set of variable-term pairs: 
{xi/ti, . . . ,Xn/tn} {xi ^ ti). This means that a{xi) = ti holds for z = 1, . . . ,n 
and (j{y) = y iov y ^ {xi, . . . ,x„}. 

Definition 3 (Unrolling). Unrolling a term s with respect to a set J of marked 
variable bindings in rational solved form is defined by 

unrollj(s) unroll’, /(s, 0) 

Let V be the set of all variables. For an arbitrary variable x S V let 
unroll’, j(x, V) 

_ Jx if X G V or there is no (x = i)^ G J, 

( unroll’ j(t, V U {x}) if x ^ V and there is a \x = t)^ € J. 



For an arbitrary term /(si, . . . , Sk) let 

unroll’,/(/(si, . . . , Sfe), U) := /(unroll’ j(si, U), . . . , unroll’j(sfc, V)) . 

There is at most one binding for every variable in (the finite set) J because J is in 
rational solved form (cf. m)- Repeated considerations of previously “unrolled” 
variables are prevented - they are stored - and so the recursion of unroll’j is 
finite. Thus, the function unroll,/ is well-defined. 

The proper substitution for variable elimination is determined by a fix-point 
of a projection function. 

Definition 4 (Projection Function). Let V be a set of variables. Further- 
more, J is an arbitrary set of marked variable bindings in rational solved form. 
Then, let 



<Pj := {x/unroll,/(x) \ x GV,x ^ unrollj(x)} 

be the largest substitution (with respect to J). For every substitution cr Q<Pj its 
codomain Cod(CT) is {t | x/t G cr}. The variables in its codomain are denoted 
by var(Cod((r))B 

The projection function (with respect to J) is the function LLj : 2'^-^ — > 2^-' 
that maps a C <L>j to 

LLj{a) := cr U {x/unroll,/(x) | x G var(Cod(cr)), x yf unrollj(x)} . 

The substitution <Fj and the function LIj are well-defined because for every 
variable x the term unroll,/(x) is uniquely determined. 

Set inclusion in 2^-' defines an partial order. Obviously, (2^-', C) is a complete 
lattice (cf. j I f)j ) . Furthermore, for every set J of variable bindings in rational 
solved form, the function LIj is monotone (cf. j 1 5] ): Let a,0 G 2'^-’ with a C 6 



The variables in a term t or in a formula F are denoted by var(t), var(F), respectively. 
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be arbitrarily chosen. Then, it holds IIj{a) C II j (9) because with cr C 0, it 
holds var(Cod(tj)) C var(Cod(0)) and consequently 

{a;/unroll,/(x) | x G var(Cod((r)), x ^ unrollj(x)} 

C {x/unrollj(x) | x G var(Cod(0)), x ^ unrollj(x)} . 

Theorem 1. For every substitution a G 2'^-^ with a C II j {a), there is a smal- 
lest, uniquely determined fix-point a* of II j such that a C a* holds. Further- 
more, there is a uq € N such that a* = Ilf {a) holds for every n > no . This 
means that a finite iteration of the operator II j on a substitution a G 2^-' cal- 
culates the fix-point a* . 

Proof. The statements are applications of a fix-point theorem due to Tarski m 
(cf. P3|, Proposition 5.2 and Proposition 5.3). □ 

3.2 Efficient Implementation Considerations 

Any naive implementation of unroll will be inefficient because the evaluation of 
unroll, /(/(x, . . . ,x)) will result in several redundant computations of unroll,/ for 
X. A worst case analysis shows the exponential complexity: 

Example 7. Let the set of marked variable bindings 

J — { (^0 — {^m— 1 — fmi^^nn • ' • j } 

' V ' ' V ^ 

xn xn 

be in rational solved form where Xq, Xi, . . . , Xm are pairwise different variables. 
For i = 1, . . . ,m, the cost 7 i_i of unroll j(xi_i) is the cost a of dereferencing a 
variable plus n-times the cost 7 / of unroll j(x/). The cost 7 ™ of unroll j(xm) is a 
(for dereferencing a variable). Thus, the cost of unroll,/(xo) is 

7o = a -I- n X 71 

= a-|-nx (a-|-nx 72 ) 

m 

— ^ n* X Of . 
i=0 

Assuming that dereferencing runs in 0(1) time, unrollj(xo) runs in 0{n'^). 

Redundant computations have to be avoided to improve efficiency. There- 
fore, a caching of a previously calculated results of unrollj(t) together with the 
considered term t in a table is strongly recommended. A simpler caching is also 
possible where only the previously determined substitutions of variables are sto- 
red. Then before any further unrolling of any term there will be looked-up in 
this table if the result is already stored there. This kind of caching will reduce 
the time complexity of unroll to be linear in the number of the considered sub- 
terms. Several appearances of sub-terms have to be counted several times, if only 
substitutions of variables are cached. 
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Theorem 2. Using caching, unroll has linear time complexity under the assump- 
tion that dereferencing and accessing an entry in the cache requires eonstant 
time. 

Proof. By induction over the number of recursions of unrollj the linear time 
complexity is proved: First, unrollj(t) is considered where t is either a constant 
or t is a variable but there is no {t = s)^ G J. In this case, unroll j(t) runs in 0(1) 
time. Second, unroll, /(t) is considered where t is either the term /(si, . . . , s„) or t 
is a variable and there is a (t = /(si, . . . , Sn))^ G J. In this case, unroll, /(t) runs 
in 0(l)+0(fci) + - • --\-0{kn) time (worst case: there is no entry for t in the cache). 
By induction hypothesis, it holds that ki is the number of sub-terms in si, k 2 
the number of sub-terms in S 2 not in si, etc., and is the number of sub-terms 
in Sn not in si, S 2 , . . . , Sn-i- Thus, ki-\- ■ ■ ■ k^ < K holds, where K is the number 

of all sub-terms. Consequently, unroll,/(t) runs in 0(1) -I- 0{ki) h 0{kn) = 

0(1 -I- fci -I- • • • -I- kn) = 0{K) time. □ 

The calculation of the smallest fix-point a* of II j such that cr C cr* holds 
for a given substitution a C II j (a) is a bottom-up calculation quite similar to 
the calculations required for query answering in deductive databases. In general, 
bottom-up calculation may generate the same tuples (in our context: substitu- 
tions) many times. The application of the differential method suggested in ^ 
EE] will avoid this kind of inefficiency. Using this approach, the substitutions 
a:/unroll, 7 (x) during each iteration are constructed by exploiting only the new 
variables introduced by the generated substitutions during the previous itera- 
tion. 

4 Early Projection 

Considering 1 1 1)11 I j . early projection is the immediate elimination of some of in- 
troduced local variables and the constraints containing them. Transformed to 
CHR applications, early projection is the substitution of some of the introduced 
local variables and the elimination of their bindings in each transition step. Eli- 
mination at each rule application requires some modifications of the operational 
semantics of CHR. Obviously, it must be correct with respect to the declara- 
tive semantics of CHR (cf. [I I ,'3123] 1 . Furthermore, these modifications must be 
compatible with the adaptation algorithms presented in I2ni. 

Using the fix-point property of Uj, it is possible to modify the previously 
presented transitions in that way: 

Si-Simplify 

{p @ H G \ U, B) is a fresh variant of a simplification rule in P 
with variables x and it holds entail(5;, I, {H = H') A G) = (T, J, D)^ . 



(Ff' A Cj/, (T, /, A))p ^p{x,H',j,D,s) 

{Gu A unify(||Ba*f (T, / U || J,. f A))) 
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S|-Propagate 

{p @ H ^ G \ U, B) is a fresh variant of a simplification rule in P 
with variables x and it holds entail(a;, I, {H = H') A G) = (T, J, D)^ . 



{H' ACu,{T,I,A))- ^p(x,h',j,d,s) 

{H' ACuA ||C/(T*f unify(||Ba*f u{p}^ j ^ || ||Su{p}^ 

In both cases, let cr* be the smallest fix-point of Uj such that 
cr := {x/unrollj(a;) | x £ var(B,B),x unrollj(a;)} C a* 
holds and let 



Jcr* '■= {(a; = CT*(a;))® | x G var(Cod(cr*)), x cr*(x)} . 

The substitution a* is the most general substitution that maps the variables in 
U and B to its substitutes because a* is the smallest fix-point with the property 
a = {x/unrollj(x) | x G var(C/, i?),x yf unroll, /(x)} C a*. Thus, only the local 
variables that are not eliminable are retained in 

The evaluation of the fix-point is necessary because we consider rational 
instead of finite trees: 

Example 8. Let X be the only variable in the body of an CHR that is applied 
to some constraints. Furthermore, let {(X = f{Y))^, {Y = g{Y))^} be the con- 
sidered set of marked variable bindings in rational solved form. Thus, unrolling 
is not sufficient to calculate the proper substitution. Unrolling of X results in 
the substitution {X/f{g{Y))} but the binding of Y is also needed for the com- 
patibility of this kind of projection with the operational semantics of CHR. For 
instance, if there is a constraint c{X) replaced by c{f{g{Y)) during elimination 
of X and Y the CHR c(f (Z)) <=> Z = g(Z) I d(Z) is no longer applicable, 
because Y = g{Y) is eliminated and thus Z ^ Y A Z = g{Z) is not entai- 
led by the built-in store. Fix-point evaluation results in the correct substitu- 
tion {X/ f{g{Y)),Y/g{Y)}. Thus, the binding Y = g{Y) is not eliminated and 
the CHR c(f(Z)) <=> Z = g(Z) I d(Z) is still applicable because Y = g{Y) 
entails Z = Y A Z = g{Z). 

More formally, early projection keeps the states in a CHR derivation logically 
equivalent: 

Theorem 3. Let V he the declarative semantics of a given set of CHR and let 
So '-A- ■ ■ ■ Sn be a sequence of Sf-Simplify and Sf-Propagate transitions based 
on these CHR. Then V,Ef \= V(5'o gg S'„) holds. 

A CHR is applicable to a state in a CHR derivation without early projection 
(Simplify and Propagate transistions only) if and only if it is applicable to the 
corresponding state in the derivation with early projection (Sf -Simplify and bij,- 
Propagate transitions only). 
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Proof. With respect to the notations in Sj^-Simplify and Sj,-Propagate we prove 

1. E* ^ {I AJ AB) ^ {I A J^. A Ba*) 

2. E* ^ (/ A Jcr* A Ba*) -A 3z{I AJAB) where 2 are the eliminated variables, 
i.e. the variables in J,B but not in J„»,Ba*. 

3. E* \= {I A J AB) ^ 3xG if and only if Ef \= {I A Ja-* A Ba*) -A 3xGa* . 
Here x are the variables only occurring in G. 

Proposition 1 holds per definition of unroll and the axioms in Ef: Unrolling a 
term is the application of the axioms of the equivalence relation ‘=’ (reflexivity, 
symmetry, transitivity) and the axiom 

Vxi . . . 'ixn'^yi . . . \/yn (xi = yi A . . . A Xn = y-n) ^ f{xi ,...,x„) = f{yi,...,yn) 

that holds for every n-ary function symbol /. By induction over the number of 
recursions of unrollj it is proved that for every term t 

E* \= J ^ t = unroll, /(t) 

holds. First, unroll, /(t) is considered where t is either a constant or t is a variable 
but there is no {t = s)^ € J. In this case, unroll,/(t) = t holds and by reflexivity 
Ef \= J ^ t = unrollj(t) holds. Second, unroll,/(t) is considered where t is either 
a term /(si, . . . , s„) or t is a variable and there is a (t = /(si, . . . , Sn))^ G J- 
By induction hypothesis 



Ef \= J ^ Si = unroll,/(sj) 

holds for i = l,...,n. As a consequence, E* \= J ^ . . . , s„) A 

/(unroll,/(si), . . . , unroll,/(s„)) implies E* \= J ^ t = unrollj(t), either direc- 
tly or by use of transitivity. Concluding, proposition 1 holds per definition of a* 
and Ja*. 

Now, let TZE be the structure of the rational trees and V be the set of all 
variables. To prove proposition 2, we consider an arbitrary variable assignment 
X : V — >■ TZT that maps variables to rational trees and satisfies the equations 
in / A Jcr* A Ba* . We have to show that there is a variable assignment f with 
x(v) = 4>(y) for every variable v ^ z that satisfies the equations in J and B. 
Therefore, we consider an arbitrary marked equation in J, say {y = t)^ . If y G z 
it is easy to assign a rational tree to the eliminated variable y such that the 
equation is satisfied. No conflict will arise because J is in rational solved form. 
If y is not eliminated (i.e. y ^ z) then y is in the codomain of cr*. Furthermore, 
y = a*{y) is an equation in because J is in rational solved form and thus 
y unroll,/(y). Thus, </>(y) := xi.v) = xi<x*{y)) = x(<x*(t)) = x(f) holds per 
definition of cr* and the properties of unroll (see above). It follows that (j>{t) = 
(j){ta*) holds for every term t. Obviously 4>{s) = (j){sa*) = (j){ta*) = (j){t) holds 
for every {sa* = ta*)^ G Ba* and thus for every (s A g B. Consequently, 
Ef^{I A Ja- A Ba*) -A 3z{I A J A B) holds. 

The proof of proposition 3 is split into two parts: the “if” -case and the “only 
if” -case. 
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In the “if” -case let x be an arbitrary variable assignment that satisfies I A 
JAB. Using proposition 1 it follows that x also satisfies / A A Ba* . Thus, x 
satisfies 3xG(j* and especially J. This means that there is a variable assignment (j) 
with x(^) = i'ij) for every variable v ^ x. Furthermore, (j)(t) = (j)(ta*) per 
definition of unrollj, a* and because x is disjoint to the codomain of cr* and to 
{y \ y ^ a*{y)}. Thus, </> satisfies G and therefore, x satisfies 3xG. 

In the “only-if”-case let x be an arbitrary variable assignment that satisfies 
I A Jct* ABa* . Using proposition 2 it follows that there is a variable assignment (j) 
with x(r') = for every variable v (N.B.: ~z are the eliminated variables) 
that satisfies I A J A B. Thus, (j) satisfies 3xG. As a consequence, x satisfies 
3xGa* because the variables in Ga* are disjoint to z. 

The first proposition in Theorem 01 follows from proposition 1, 2 and the 
axiom 

Vxi . . . Vx^Vj/i . ..Vyn {xi=yiA...AXn = Ap(xi, . . .,Xn)) -A p{yi, ...,yn) ■ 

in E* that holds for every n-ary predicate symbol p. 

The second proposition in Theorem 0 is a consequence of proposition 3. □ 

The proposed early projection is an in situ operation because it is applied 
together with a CHR and not after the rule application. Despite of the additional 
computational effort, the advantages of the early projection are obvious if we 
consider the constraint problem in Example 0 and its solution. Retaining the 
sequence of rule applications, the resulting CHR derivation is strongly shortened 
and simplified: 

{{7X + 1Y = 3)fif A (?r = 2)f2} A {lU - ?U = 2)f3> a (?[/ +7V = 0)f^> , 

(T, 0, W)) {xy.uy} 

{{IX + 1Y = 3)fi> A {lU -W = 2)f3} A {lU + 7V = 0)f^>, 

{{7U -7V = 2)f3} A {7U + 7V = 0)f^>, 

(T, {{Y = 2)f2}, {X = l)fb2}}^ \])){xx,uy} 

((?C/ + ?U = 0)f3.4}^ 

(T, {(y = 2)W, (X = (Jj ^ i){3,4}|^ [])){x.F.C/.y} 

^P3 (T, (T, {(F = 2)f2}, {X = {U = 

Within the application of a variant of the rule pi, the considered set of 
variable bindings is J\ = {(Pi = , {C\ = 2)f^f}. A first application of 

calculates the fix-point 

PA({Pi/y,Ci/2}) = {Pi/r,Ci/2} . 

Hence, the additional computational overhead is quite small. The application of 
the obtained substitution a* = (Pi/F, Ci/2} to the equation Pi A Gi in the 
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body of the rule results in the equation V = 2 which is added to the built-in store. 
Obviously, Jcr* is the identity because var(Cod(crJ‘)) = {Y} only contains global 
variables. Consequently, all the introduced local variables and their bindings are 
immediately eliminated. Early projection is quite similar in the remaining rule 
applications. In particular, the evaluation of the fix-points requires in all cases 
just one iteration step of II and all introduced local variables and their bindings 
are immediately eliminated, too. 

Obviously, the fix-point calculation requires one iteration step and all the 
introduced variables are immediately eliminated if the variables in the body 
of the rule occur in its head or they will be bound to ground terms, e.g. to 
results of arithmetic calculations. Normally, this is the case in practical constraint 
processing, where the values of previously undetermined variables are evaluated. 

During the adaptation of CHR derivations, rule applications that lose their 
justifications are tried to be applied again. Therefore, head matching and guard 
entailment has to be decided again and the local variables bindings have to 
be recalculated using entail. If the head matches again the chosen constraints 
and the guard is entailed again, the rule is applied to the current state and 
a successor state is calculated, up to now, without any variable elimination. 
An application of early projection within the calculation of the successor state 
immediately eliminates the introduced variables and their bindings. In analogy 
to the modification of the transitions, the substitutions and eliminations are 
performed. 

5 Answer Projection 

A simpler form of projection is answer projection. In contrast to early projec- 
tion, where variables are eliminated in each state of a CHR derivation, only the 
variables in the final state of a CHR derivation are eliminated. In detail, answer 
projection is the elimination of all existentially quantified variables and their 
bindings in the consistent final state {Cu, (T, I, of a CHR derivation. Thus, 
the constraints on the global variables v are exemplified. If the final state is 
inconsistent, there is no need for any projection, because it is equivalent to false. 
The main goal of answer projection is the improvement of the readability of the 
answer of constraint processing, i.e. the better readability of the constraints in 
its final state. Improved efficiency or memory usage is not the goal of answer 
projection. 

The realization of answer projection is quite similar to early projection: In 
its first step the smallest fix-point cr* of II j is calculated such that 

a := {x/unroll/(x) I x G V U var(C'c/), X yf unroll/(a;)} C a* 

holds. Then the state {Cu,{T,I,A))- is replaced by the answer {Cua*,{x = 
(J*{x) I X yf cr*(a^)})^ 7 - The justifications of the constraints in the user-defined 
store Cucr* have to be ignored. Ignoring the justifications of the constraints, it 
holds 

V, E* h {Cu M)^3z {Cua* A /\ (x = a*(x)) , 

X^(7* (ic) 
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where V is the logical reading, i.e. the declarative semantics, of the applied CHR. 
The variables y are the variables in the final state and z are the variables in the 
answer, respectively, that are not contained in v. 

The application of answer projection to the final state in Example 0 results 
in a better readable, more appropriate answer 

(T, {r = 2, X = 1, C/ = 1, E = -1})^X,Y,U,V} ■ 

Answer projection is not compatible to adaptation of CHR derivations af- 
ter constraint addition or deletions, because variables are substituted in the 
constraints without adaptation of their justifications. For instance, if answer 
projection is applied to the state ((eq(Al, (T, {(E A 2)^^^, the 

answer is ((eq(X, 2))^^^^, with an improperly justified constraint eq(Al, 2). 

Its proper justification is {1,2}. 

6 Conclusion and Future Work 

Constraint processing using CHR introduces a lot of local variables and their 
bindings. The constraint stores become quite large and the really relevant infor- 
mation is hidden. Furthermore, the adaptation of CHR derivation after constraint 
deletions requires the deletion of several superfluous variable bindings. To over- 
come this insufficiencies, the principle of projection is proposed. The presented 
early projection method, immediately eliminates the maximal number of intro- 
duced variables at each CHR derivation step. This kind of projection keeps the 
states in a CHR derivation quite small and is compatible with the already presen- 
ted adaptation algorithms. Thus, adaptation of CHR derivations especially after 
deletions of constraints may be faster because the amount of variable bindings 
to be considered and eventually deleted is reduced. 

An open question is, in which cases the additional effort that is needed for 
early projection pays off. It is not clear which (dynamic) constraint problems 
will be solved more efficiently using early projection and how strong memory 
requirements will be reduced. The decision, whether to use early projection or 
not, depends on the constraint problem to be solved. Hopefully, we assume a 
runtime improvement and reduced memory requirement in all practical applica- 
tions of CHR. Up to now, runtime analysis that show the improvements are still 
missing. 

From our point of view, answer projection should be used if the computational 
effort that is required for the proposed early projection will not pay off. In all 
other cases early projection is recommended. 

The advantages and disadvantages of early projection during the solution of 
linear equations and inequations are discussed in [H)lf fj . There, it is proposed to 
apply projection only in these cases, where the additional computational effort is 
quite small. In our context, this is the case if the mentioned criteria are satisfied 
and the fix-point evaluation requires at most one iteration step. 

For the future, the implementation of the projection functions and the mo- 
dified operational semantics of the CHR is planned. Based on the realization of 
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the proposed early projection and the proposed modification of the adaptation 
algorithm we will make some runtime analysis. Using randomly generated CHR 
derivations and derivations stemming from real applications of CHR, the run- 
time results of the adaptations with and without variable elimination will be 
compared. 

References 

1. Slim Abdennadher. Operational semantics and confluence of constraint handling 
rules. In Proceedings of the Third International Conference on Principles and 
Practice of Constraint Programming - CP97, number 1330 in Lecture Notes in 
Computer Science. Springer Verlag, 1997. 

2. Slim Abdennadher, Thom Friihwirth, and Holger Meuss. On confluence of con- 
straint handling rules. In Eugene C. Freuder, editor. Proceedings of the Second 
International Conference on Principles and Practice of Constraint Programming - 
CP96, number 1118 in Lecture Notes in Computer Science, pages 1-15. Springer 
Verlag, 1996. 

3. Slim Abdennadher, Thom Friihwirth, and Holger Meuss. Confluence and semantics 
of constraint simplification rules. Constraints, 4(2): 133-165, May 1999. ISSN 1383- 
7133. 

4. I. Balbin and K. Ramamohanarao. A differential approach to query optimization 
in recursive deductive databases. Technical Report 7, Department of Computer 
Science, University of Melbourne, April 1986. 

5. F. Bancilhon. Naive evaluation of recursively defined relations. In Proceedings 
of the Islamorada Workshop on Large Scale Knowledge Base Reasoning Systems, 

1985. 

6. R. Bayer. Query evaluation and recursion in deductive database systems. Techni- 
scher bericht, Institut fiir Informatik, Technische Universitat Miinchen, 1998. 

7. Bruno Courcelle. Fundamental properties of infinite trees. Theoretical Computer 
Science, 25(2):95-169, March 1983. 

8. Johan de Kleer. Choices without backtracking. In Ronald J. Brachman, edi- 
tor, Proceedings of the National Conference on Artificial Intelligence, pages 79-85, 
Austin, TX, August 1984. William Kaufmann. 

9. Johan de Kleer. An assumption-based TMS. Artificial Intelligence, 28:127-162, 

1986. 

10. Andreas Fordan and Roland Yap. Early projection in CLP(77). In Proceedings 
of the fth International Conference on Principles and Practice of Constraint Pro- 
gramming, CP‘98, number 1520 in Lecture Notes in Computer Science, pages 177- 
191. Springer Verlag, 1998. 

11. Andreas Fordan and Roland Yap. Towards early projection in CLP(77). In Pro- 
ceedings of the JICSLP Conference, Poster-Session. The MIT Press, 1998. 

12. Thom Friihwirth. Constraint Handling Rules. In Andreas Podelski, editor. Con- 
straint Programming: Basics and Trends, number 910 in Lecture Notes in Compu- 
ter Science, pages 90-107. Springer Verlag, March 1995. 

13. Thom Friihwirth. Theory and practice of constraint handling rules. The Journal 
of Logic Programming, 37:95-138, 1998. 

14. Thom Friihwirth and Slim Abdennadher. Constraint-Programmierung. Springer 
Verlag, 1997. ISBN 3-540-60670-X. 




338 



A. Wolf 



15. John Wylie Lloyd. Foundations of Logic Programming. Springer Verlag, second, 
extended edition, 1987. 

16. Michael J. Maher. Complete axiomatizations of the algebras of finite, rational and 
infinite trees. In Proc. of the 3rd IEEE Annual Sumposium on Logic in Computer 
Science, pages 348-357, Edinburgh, Scotland, July 1988. IEEE, Computer Society 
Press. 

17. John McCarthy. Recursive functions of symbolic expressions and their computation 
by machine. Communications of the ACM, 3(3), 1960. 

18. Michael Reinfrank. Fundamentals and Logical Foundations of Truth Maintenance. 
Dissertation no. 221, Department of Computer and Information Science, Linkoping 
University, Sweden, 1989. 

19. Volker Sperschneider and Grigorios Antoniou. Logic: A Foundation for Computer 
Science. Addison Wesley, 1991. 

20. Alfred Tarski. A lattice-theoretic hxpoint theorem and its applications. Pacific 
Journal of Mathematics, 5(2):285-309, 1955. 

21. Armin Wolf. Adaptive entailment of equations over rational trees. In Uwe Egly 
and Hans Tompits, editors, Proceedings of the 13th Workshop on Logic Program- 
ming, WLP‘98, number 1843-1998-10 in Technical Report, pages 25-33. Vienna 
University of Technology, October 1998. 

22. Armin Wolf. Adaptive solving of equations over rational trees. In Proceedings 
of the Fourth International Conference on Principles and Practice on Constraint 
Programming, CP‘98, Poster Session, number 1520 in Lecture Notes in Computer 
Science, page 475. Springer, 1998. 

23. Armin Wolf. Adaptive Constraintverarbeitung mit Constraint-Handling-Rules - 
Ein allgemeiner Ansatz zur Losung dynamischer Constraint- Probleme, volume 219 
of Disserationen zur Kiinstlichen Intelligenz (DISKI), infix, Ringstrafie 32, 53757 
Sankt Augustin, November 1999. ISBN 3-89601-219-3. 




Author Index 



Abdel-Rahman, Samir E. 188 
Apt, Krzystof R. 91 

Bahgat, Reem 188 
Bartak, Roman 237 
Behnamou, Frederic 1 
Bistarelli, S. 108 

Codognet, Philippe 17, 108 

Demoen, Bart 256 
Di Pierro, Alessandra 212 
Dubois, Hubert 274 

Faltings, Boi 173 
Friihwirth, Thom 298 

Gent. Ian 134 
Georget, Y. 108 
Goualard, Frederic 1 
Granvilliers, Laurent 1 



Janssens, Gerda 256 

Kirchner, Helene 274 

Michel, L. 75 
Monfroy, Eric 150 

Ringeissen, Christophe 150 
Rossi, Francesca 40, 108 

Sam-Haroud, Djamila 173 
Silaghi, Marius-G. 173 
Stergiou, Kostas 134 

Van Hentenryck, Pascal 75 
Vandecasteele, Henk 256 

Walsh, Toby 134 
Wiklicky, Herbert 212 
Wolf, Armin 318 




